Method, device and computer storage medium for communication

Abstract

Embodiments of the present disclosure relate to methods, devices, and computer-readable media for communication. The method for communication implemented by a terminal device includes: generating a first control element of a media access control layer in an inactive state, the first control element carrying a first identifier of the terminal device; and sending the first control element and uplink data to a network device. The method for communication implemented by a network device includes: receiving a first control element and uplink data from a terminal device; and sending uplink data to a core network element. In this way, small data transmission can be achieved with reduced signaling overhead in an inactive state of the terminal device.

Description

Technical Field

[0001] The disclosed embodiments generally relate to the field of telecommunications, and more particularly to methods, devices, and computer storage media for communication of small data transmissions. Background Art

[0002] Typically, a terminal device in an inactive state may still have small and infrequent data traffic to send (hereinafter also referred to as small data transfers). Prior to the Third Generation Partnership Project (3GPP) Release 16, the inactive state could not support data transfers, and the terminal device had to restore the connection for any downlink and uplink data. No matter how small and infrequent the data packets were, connection establishment and subsequent release to the inactive state occurred for each data transfer. This would result in unnecessary power consumption and signaling overhead.

[0003] In this case, 3GPP Release 17 has approved small data transmission based on a random access channel (RACH) in an inactive state. If small data transmission can be performed without a radio resource control (RRC) message, the signaling overhead can be further reduced. Therefore, how to perform small data transmission without RRC signaling has become a hot issue. Summary of the invention

[0004] In general, embodiments of the present disclosure provide methods, devices, and computer storage media for communication of small data transfers.

[0005] In a first aspect, a method for communication is provided, comprising: generating a first control element of a media access control layer at a terminal device in an inactive state, the first control element carrying a first identifier of the terminal device; and sending the first control element and uplink data to a network device.

[0006] In a second aspect, a method for communication is provided, comprising: receiving, at a network device, a first control element of a media control layer and uplink data from a terminal device, the first control element carrying a first identifier of the terminal device; and sending the uplink data to a core network element.

[0007] In a third aspect, a terminal device is provided. The terminal device includes a processor and a memory coupled to the processor. The memory stores instructions, which, when executed by the processor, cause the terminal device to perform the method according to the first aspect of the present disclosure.

[0008] In a fourth aspect, a network device is provided. The network device includes a processor and a memory coupled to the processor. The memory stores instructions, which, when executed by the processor, cause the network device to perform the method according to the second aspect of the present disclosure.

[0009] In a fifth aspect, a computer readable medium having instructions stored thereon is provided. The instructions, when executed on at least one processor, cause the at least one processor to perform the method according to the first aspect of the present disclosure.

[0010] In a sixth aspect, a computer readable medium having instructions stored thereon is provided. The instructions, when executed on at least one processor, cause the at least one processor to perform the method according to the second aspect of the present disclosure.

[0011] Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The above and other objects, features and advantageous effects of the present disclosure will become more apparent through a more detailed description of some embodiments of the present disclosure in the accompanying drawings, in which:

[0013] Figure 1 shows an example communication network in which some embodiments of the present disclosure may be implemented;

[0014] Figure 2 A schematic diagram illustrating a communication process for small data transmission according to some embodiments of the present disclosure is shown;

[0015] Figure 3 A schematic diagram illustrating a communication process during a 4-step RACH process according to some embodiments of the present disclosure is shown;

[0016] Figure 4 A schematic diagram illustrating a communication process during a 2-step RACH process according to some embodiments of the present disclosure is shown;

[0017] Figure 5 An example communication method implemented at a terminal device according to some embodiments of the present disclosure is shown;

[0018] Figure 6 A schematic diagram illustrating implementation of a media access control layer control element (MAC CE) carrying first authentication information and a first identifier for a terminal device according to some embodiments of the present disclosure is shown;

[0019] Figure 7 A schematic diagram illustrating another implementation of a MAC CE carrying first authentication information and a first identifier for a terminal device according to some embodiments of the present disclosure is shown;

[0020] Figure 8 A schematic diagram illustrating the implementation of a MAC CE carrying contention resolution information for a 4-step RACH procedure according to some embodiments of the present disclosure is shown;

[0021] Fig. 9 A schematic diagram illustrating implementation of a successful random access response (RAR) carrying contention resolution information for a 2-step RACH procedure according to some embodiments of the present disclosure is shown;

[0022] Fig.10 Another exemplary communication method implemented at a terminal device according to some embodiments of the present disclosure is shown;

[0023] Fig.11 Another exemplary communication method implemented at a terminal device according to some embodiments of the present disclosure is shown;

[0024] Fig.12 An example communication method implemented at a network device according to some embodiments of the present disclosure is shown;

[0025] Fig.13 Another example communication method implemented at a network device according to some embodiments of the present disclosure is shown; and

[0026] Fig.14 is a simplified block diagram of a device suitable for implementing embodiments of the present disclosure.

[0027] Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. DETAILED DESCRIPTION

[0028] The principle of the present disclosure will now be described with reference to some embodiments. It should be understood that these embodiments are described only for illustrative purposes and to help those skilled in the art understand and implement the present disclosure without implying any limitation on the scope of the disclosure. The disclosure described herein can be implemented in various ways different from the modes described below.

[0029] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art.

[0030] As used herein, the term "terminal device" refers to any device with wireless or wired communication capabilities. Examples of terminal devices include, but are not limited to: user equipment (UE), personal computer, desktop, mobile phone, cellular phone, smart phone, personal digital assistant (PDA), portable computer, tablet computer, wearable device, Internet of Things (IoT) device, Internet of Everything (IoE) device, machine type communication (MTC) device, vehicle-mounted device for V2X communication (where X represents pedestrian, vehicle or infrastructure / network), or image capture device such as digital camera, gaming device, music storage and playback device, or Internet tool that allows wireless or wired Internet access and browsing, etc. The term "terminal device" can be used interchangeably with UE, mobile station, subscriber station, mobile terminal, user terminal or wireless device. In addition, the term "network device" refers to a device that can provide or host a cell or coverage with which a terminal device can communicate. Examples of network devices include, but are not limited to, Node B (NodeB or NB), evolved Node B (eNodeB or eNB), next generation Node B (gNB), transmit receive point (TRP), remote radio unit (RRU), radio head (RH), remote radio head (RRH), low power nodes such as femto nodes, pico nodes, etc.

[0031] In one embodiment, the terminal device may be connected to a first network device and a second network device. One of the first network device and the second network device may be a primary node, and the other may be a secondary node. The first network device and the second network device may use different RATs. In one embodiment, the first network device may be a first RAT device, and the second network device may be a second RAT device. In one embodiment, the first RAT device is an eNB and the second RAT device is a gNB. Information related to different RATs may be sent from at least one of the first network device and the second network device to the terminal device. In one embodiment, the first information may be sent from the first network device to the terminal device, and the second information may be sent from the second network device to the terminal device directly or via the first network device. In one embodiment, information related to the configuration of the terminal device configured by the second network device may be sent from the second network device via the first network device. Information related to the reconfiguration of the terminal device configured by the second network device may be sent from the second network device to the terminal device directly or via the first network device.

[0032] As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "including" and its variations are to be interpreted as open-ended terms, which mean "including but not limited to". The term "based on" is to be interpreted as "based at least in part on". The terms "one embodiment" and "embodiment" are to be interpreted as "at least one embodiment". The term "another embodiment" is to be interpreted as "at least one other embodiment". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may be included below.

[0033] In some examples, values, processes, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," etc. It should be understood that such descriptions are intended to indicate that a selection may be made among a number of functional alternatives used, and that such a selection is not necessarily better, lesser, higher, or more preferred than other selections.

[0034] Figure 1 1 shows a schematic diagram of an example communication network 100 in which embodiments of the present disclosure may be implemented. Figure 1 As shown, the communication network 100 may include a network device 110 and a terminal device 120 served by the network device 110. The network device 110 may communicate with the terminal device 120 via a channel such as a wireless communication channel.

[0035] The communication network 100 may further include a core network element 131 located in the core network 130. For example, in some embodiments, the core network element 131 may perform a user plane function (UPF). It should be noted that the core network element 131 may perform any other additional functions, and the present application is not limited in this regard.

[0036] The terminal device 120 may communicate with the core network element 131 via the network device 110. For example, the terminal device 120 may send a data packet (i.e., uplink data) to the network device 110, and the network device 110 may send the uplink data to the core network element 131. Thus, the core network element 131 may send a data packet (i.e., downlink data) to the network device 110, and the network device 110 may send the downlink data to the terminal device 120.

[0037] It should be understood that Figure 1 The number of devices in is given for illustrative purposes and does not imply any limitation to the present disclosure. The communication network 100 may include any suitable number of network devices and / or terminal devices and / or core network elements suitable for implementing the present disclosure.

[0038] The communication in the communication network 100 may conform to any suitable standard, including but not limited to: Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE Evolution, Advanced LTE (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), GSM EDGE Radio Access Network (GERAN), Machine Type Communication (MTC), etc. In addition, the communication may be performed according to any generation of communication protocols currently known or to be developed in the future. Examples of communication protocols include but are not limited to: first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocols.

[0039] As described above, the terminal device 120 in an inactive state may still have small and infrequent data traffic to be sent. In some embodiments, small and infrequent data traffic may include smart phone applications, such as traffic from instant messaging (IM) services (whatsapp, QQ, wechat, etc.), heartbeat / keep-alive traffic from IM / email clients and other applications, and push notifications from various applications. In some embodiments, small and infrequent data traffic may include non-smart phone applications, such as traffic from wearable devices (periodic positioning information, etc.), sensors (industrial wireless sensor networks that periodically or in an event-triggered manner send temperature, pressure readings, etc.), and smart meters and smart meter networks that send periodic meter readings.

[0040] Currently, a RACH-based solution without RRC messages has been proposed to perform small data transmission in order to reduce signaling overhead. However, no more detailed solution has been proposed. The embodiment of the present disclosure provides a communication solution for small data transmission. The solution can realize small data transmission in an inactive state of a terminal device with reduced signaling overhead. The principle and implementation of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0041] Figure 2 FIG. 2 is a schematic diagram showing a communication process 200 for small data transmission according to some embodiments of the present disclosure. For the purpose of discussion, reference will be made to FIG. Figure 1 Describe process 200. Process 200 may involve Figure 1 The terminal device 120, the network device 110 and the core network element 131 are shown.

[0042] like Figure 2As shown, the terminal device 120 in the inactive state generates 210 a first media access control layer control element (MAC CE). The first MAC CE carries a first identifier of the terminal device 120. The first identifier refers to an identifier used by the terminal device 120 in the inactive state. In some embodiments, the first identifier may be a temporary identifier of the terminal device 120 in the inactive state, for example, an inactive radio network temporary identifier (I-RNTI).

[0043] In some embodiments, if the uplink data to be sent at the terminal device 120 is associated with a small and infrequent data service, the terminal device 120 may generate a first MAC CE. In some embodiments, the first MAC CE may be newly defined. Compared with the RRC message carrying the first identifier, the first MAC CE carrying the first identifier may significantly reduce signaling overhead.

[0044] After generating the first MAC CE, the terminal device 120 sends the first MAC CE and uplink data. In some embodiments, the terminal device 120 may send the first MAC CE and uplink data in a physical uplink shared channel (PUSCH). In some embodiments, the terminal device 120 may send the first MAC CE and uplink data during a 4-step RACH procedure. In some embodiments, the terminal device 120 may send the first MAC CE and uplink data during a 2-step RACH procedure.

[0045] Therefore, upon receiving the first MAC CE and the uplink data, the network device 110 sends the uplink data to the core network element 131. In some embodiments, the terminal device 120 may only send the uplink data to the network device 110 without waiting for any contention resolution. In this case, the network device 110 may not configure a contention resolution timer or a RAR window for the terminal device 120. In some alternative embodiments, the terminal device 120 may receive the result of the contention resolution. Figure 3 and Figure 4 This is described in more detail.

[0046] Figure 3 A schematic diagram of a communication process 300 during a 4-step RACH process according to some embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1 Process 300 is described. Process 300 may include the following: Figure 1 The terminal device 120, the network device 110 and the core network element 131 are shown.

[0047] like Figure 3As shown, the terminal device 120 in an inactive state may send 301 a random preamble sequence to the network device 110. In some embodiments, the terminal device 120 may send the random preamble sequence in the RACH. In some embodiments, if the uplink data to be sent at the terminal device 120 is associated with a small and infrequent data service, the terminal device 120 may send the random preamble sequence. Therefore, the terminal device 120 may receive 302 a RAR from the network device 110. The RAR may include a temporary cell radio network temporary identifier (TC-RNTI).

[0048] Then, the terminal device 120 may generate 303 a first MAC CE carrying a first identification (e.g., I-RNTI) of the terminal device 120. In some embodiments, the first MAC CE may also carry first authentication information for the terminal device 120, and the first identification and the first authentication information are in different fields of the first MAC CE. In some alternative embodiments, the terminal device 120 may also generate 304 a second MAC CE carrying the first authentication information for the terminal device 120. The first authentication information is used to verify the validity of the terminal device 120 at the network device 110. For example, the first authentication information may be in the form of a short message authentication code for integrity (ShortMAC-I).

[0049] The terminal device 120 may send 305 the first MAC CE and the uplink data to the network device 110. In some embodiments where the terminal device 120 needs to be authenticated by the network device 110, the terminal device 120 may send the first MAC CE, the uplink data, and the second MAC CE to the network device 110. In some embodiments, the terminal device 120 may send the first MAC CE, the uplink data, the second MAC CE, and a buffer status report (BSR) to the network device 110. The BSR may indicate an amount of remaining uplink data to be sent.

[0050] For transmission 305, the information transmitted is scrambled by the TC-RNTI. In some embodiments, when network device 110 needs to forward uplink data to core network element 131 and wait for downlink data from core network element 131, an extended contention resolution timer may be started. In some embodiments for a 4-step RACH procedure, a longer contention resolution timer may be used, for example, ENUMERATED {sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64, sf80, sf100, sf120, sf160, sf200, sf240, sf480, sf960, sf1920, sf3840, sf5760, sf7680, sf10240}.

[0051] In some embodiments, the extended contention resolution timer may be broadcast by system information.In some alternative embodiments, the extended contention resolution timer may be configured to the terminal device 120 by using a dedicated RRC message.

[0052] In some embodiments where verification of the terminal device 120 by the network device 110 is required, the network device 110 may determine the first authentication information from the second MAC CE and verify 306 the validity of the terminal device 120 based on the first authentication information. In some embodiments, if the terminal device 120 is determined to be valid, the network device 110 may send 307 uplink data to the core network element 131. In some embodiments, if the terminal device 120 is determined to be invalid, the network device 110 may discard the uplink data. In some embodiments where there is downlink data to be sent from the core network element 131, the network device 110 may receive 308 the downlink data from the core network element 131.

[0053] The network device 110 may generate 309 a third MAC CE carrying contention resolution information and send 310 the third MAC CE to the network device 110. In some embodiments, the contention resolution information may include an identification of the terminal device for which the contention resolution was successful. In some embodiments, the network device 110 may send the third MAC CE in a physical downlink shared channel (PDSCH).

[0054] Assume that the contention resolution information includes the first identification of the terminal device 120. In some embodiments where it is necessary to authenticate the network device 110 at the terminal device 120, the network device 110 may generate a fourth MAC CE carrying second authentication information for the network device 110. For example, the second authentication information may be in the form of a ShortMAC-I. In this case, the network device 110 may send the fourth MAC CE to the terminal device 120 together with the third MAC CE.

[0055] In some embodiments in which the network device 110 receives a BSR indicating that there is still remaining uplink data to be sent, the network device 110 may send uplink grant information with the third MAC CE to the terminal device 120. In some additional embodiments, the network device 110 may send the third MAC CE, the fourth MAC CE, and the uplink grant information to the terminal device 120.

[0056] In some embodiments where the network device 110 receives downlink data destined for the terminal device 120 from the core network element 131 , the network device 110 may send the third MAC CE, the fourth MAC CE, the uplink grant information, and the downlink data to the terminal device 120 .

[0057] After receiving the third MAC CE including the first identity of the terminal device 120, the terminal device 120 may perform subsequent data transmission by using the TC-RNTI as a cell radio network temporary identifier (C-RNTI). At this time, the terminal device 120 is still in an inactive state.

[0058] In some embodiments, terminal device 120 may verify 311 the validity of network device 110 based on the second authentication information received from network device 110. If network device 110 is determined to be valid, terminal device 120 may accept the received downlink data. If network device 110 is determined to be invalid, terminal device 120 may discard the received downlink data.

[0059] The terminal device 120 may send 312 at least a portion of the remaining uplink data and the BSR to the network device 110. In some embodiments, in response to receiving the uplink grant information, the terminal device 120 may monitor the downlink channel until the time period expires. In some alternative embodiments, in response to sending 312 at least a portion of the remaining uplink data, the terminal device 120 may monitor the downlink channel until the time period expires.

[0060] Upon receiving at least a portion of the remaining uplink data, the network device 110 may send 313 it to the core network element 131. The network device 110 may receive 314 further downlink data and further uplink grant information (if any) and send them 315 to the terminal device 120. The terminal device 120 may send 316 the remaining uplink data to the network device 110, and the network device 110 may send 317 it to the core network element 131.

[0061] The uplink and downlink data transmission may be repeated using the C-RNTI in the inactive state of the terminal device 120 as described above until the network device 110 sends 318 a connection release message indicating the end of the data transmission. If a connection release message such as an RRCRelease message is received, the terminal device 120 may initialize the inactive state of the terminal device 120.

[0062] Figure 4 A schematic diagram illustrating a communication process 400 during a 2-step RACH procedure according to some embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1 Process 400 is described. Process 400 may include the following: Figure 1 The terminal device 120, the network device 110 and the core network element 131 are shown.

[0063] like Figure 4As shown, the terminal device 120 in an inactive state may generate 401 a first MAC CE carrying a first identifier (e.g., I-RNTI) of the terminal device 120. In some embodiments, the first MAC CE may also carry first authentication information for the terminal device 120, and the first identifier and the first authentication information are in different fields of the first MAC CE. In some alternative embodiments, the terminal device 120 may also generate 402 a second MAC CE carrying the first authentication information for the terminal device 120. The first authentication information is used to verify the validity of the terminal device 120 at the network device 110. For example, the first authentication information may be in the form of a ShortMAC-I.

[0064] If the uplink data to be sent at the terminal device 120 is associated with a small and infrequent data service, the terminal device 120 may send 403 a random preamble sequence, a first MAC CE, and the uplink data to the network device 110. In some embodiments, the terminal device 120 may send the random preamble sequence in the RACH and send the first MAC CE and the uplink data in the PUSCH. In some embodiments in which the terminal device 120 needs to be authenticated by the network device 110, the terminal device 120 may send the random preamble sequence, the first MAC CE, the uplink data, and the second MAC CE to the network device 110. In some embodiments, the terminal device 120 may send the random preamble sequence, the first MAC CE, the uplink data, the second MAC CE, and the BSR to the network device 110.

[0065] For transmission 403, the information transmitted is scrambled by a random access RNTI (RA-RNTI) and a random access preamble identifier (RAPID). In some embodiments, when the network device 110 needs to forward uplink data to the core network element 131 and wait for downlink data from the core network element 131, an extended RAR window can be activated. In some embodiments for the 2-step RACH process, the RAR window needs to be further expanded to 80ms, 160ms, 320ms, 640ms..., which requires 3 bits, 4 bits, 5 bits, 6 bits..., and the least significant bit (LSB) of the system frame number (SFN) is included in the downlink control information (DCI) scheduling message (msgB).

[0066] In some embodiments, the extended RAR window may be broadcast by system information. In some alternative embodiments, the extended RAR window may be configured to the terminal device 120 by using a dedicated RRC message.

[0067] In some embodiments where verification of the terminal device 120 by the network device 110 is required, the network device 110 may determine the first authentication information from the second MAC CE, and verify 404 the validity of the terminal device 120 based on the first authentication information. In some embodiments, if the terminal device 120 is valid, the network device 110 may send 405 uplink data to the core network element 131. In some embodiments, if the terminal device 120 is invalid, the network device 110 may discard the uplink data. In some embodiments where there is downlink data to be sent from the core network element 131, the network device 110 may receive 406 the downlink data from the core network element 131.

[0068] The network device 110 may generate 407 contention resolution information and send 408 the contention resolution information in a successful RAR to the network device 110. In some embodiments, the contention resolution information may include an identification of the terminal device for which the contention resolution was successful. In some embodiments, the network device 110 may send the contention resolution information in a PDSCH.

[0069] Assume that the contention resolution information includes the first identification of the terminal device 120. In some embodiments where the network device 110 needs to be authenticated at the terminal device 120, the network device 110 may generate a fourth MAC CE carrying second authentication information for the network device 110. For example, the second authentication information may be in the form of a ShortMAC-I. In this case, the network device 110 may send the fourth MAC CE with the contention resolution information to the terminal device 120. In some embodiments, the network device 110 may send the fourth MAC CE and the contention resolution information in the PDSCH.

[0070] In some embodiments where the network device 110 receives a BSR indicating that there is still uplink data remaining to be sent, the network device 110 may send the uplink grant information together with the contention resolution information to the terminal device 120. In some additional embodiments, the network device 110 may send the contention resolution information, the fourth MAC CE, and the uplink grant information to the terminal device 120. In some embodiments, the network device 110 may send the contention resolution information and the fourth MAC CE in the PDSCH, and send the uplink grant information in a physical downlink control channel (PDCCH).

[0071] In some embodiments where the network device 110 receives downlink data destined for the terminal device 120 from the core network element 131 , the network device 110 may send contention resolution information, the fourth MAC CE, uplink grant information, and the downlink data to the terminal device 120 .

[0072] After receiving the contention resolution information including the first identity of the terminal device 120, the terminal device 120 may perform subsequent data transmission by using the C-RNTI in the successful RAR. At this time, the terminal device 120 is still in an inactive state.

[0073] In some embodiments, terminal device 120 may verify 409 the validity of network device 110 based on the second authentication information received from network device 110. If network device 110 is determined to be valid, terminal device 120 may accept the received downlink data. If network device 110 is determined to be invalid, terminal device 120 may discard the received downlink data.

[0074] The terminal device 120 may send 410 at least a portion of the remaining uplink data and the BSR to the network device 110. In some embodiments, the terminal device 120 may send the remaining uplink data and the BSR in the PDSCH. In some embodiments, in response to receiving the uplink grant information, the terminal device 120 may monitor the downlink channel until the time period expires. In some alternative embodiments, in response to sending 410 at least a portion of the remaining uplink data, the terminal device 120 may monitor the downlink channel until the time period expires.

[0075] After receiving at least a portion of the remaining uplink data, the network device 110 may send 411 it to the core network element 131. The network device 110 may receive 412 further downlink data and further uplink grant information (if any) and send them 413 to the terminal device 120. The terminal device 120 may send 414 the remaining uplink data to the network device 110, and the network device 110 may send 415 it to the core network element 131.

[0076] The uplink and downlink data transmission may be repeated using the C-RNTI in the inactive state of the terminal device 120 as described above until the network device 110 sends 416 a connection release message indicating the end of the data transmission. If a connection release message such as an RRCRelease message is received, the terminal device 120 may initialize the inactive state of the terminal device 120. It can be seen that Figure 4 The operations in steps 409-416 in Figure 3 The operations in steps 311-318 are similar.

[0077] By reference Figures 2 to 4 The described process can well perform small data transmission in the inactive state of the terminal device with reduced signaling overhead. Corresponding to these processes, the embodiments of the present application also provide communication methods implemented at the terminal device and the network device respectively. Figures 5 to 14 This is described in more detail.

[0078] Figure 5 An example communication method 500 implemented at a terminal device according to some embodiments of the present disclosure is shown. For example, the method 500 may be implemented in a Figure 1 For the purpose of discussion, reference will be made to Figure 1 Method 500 is described. It should be understood that method 500 may include additional blocks not shown and / or may omit some of the blocks shown, and the scope of the present disclosure is not limited in this regard.

[0079] like Figure 5 As shown, in block 510, the terminal device 120 generates a first MAC CE carrying a first identifier of the terminal device 120. In some embodiments, the first MAC CE may also carry first authentication information for the terminal device 120, and the first identifier and the first authentication information are in different fields of the first MAC CE. Figure 6 A schematic diagram 600 illustrating an implementation of a MAC CE 610 carrying first authentication information and a first identification for a terminal device according to some embodiments of the present disclosure is shown.

[0080] In some embodiments, MAC CE 610 may have a fixed size and may consist of two fields including an I-RNTI field and a SHORTMAC-I field. The I-RNTI field contains the I-RNTI of the MAC entity of the terminal device 120. In some embodiments, the length of the I-RNTI field may be 40 bits, such as Figure 6 The SHORTMAC-I field contains an authentication token to facilitate authentication of the terminal device 120 at the network device 110. In some embodiments, the length of the SHORTMAC-I field may be 16 bits, such as Figure 6 This is shown as bytes 616-617 in .

[0081] In some alternative embodiments, the terminal device 120 may also generate a second MAC CE carrying the first authentication information for the terminal device 120. The second MAC CE is separate from the first MAC CE. Figure 7 A schematic diagram 700 is shown of another implementation of a MAC CE 710 carrying a first identification and a MAC CE 720 carrying first authentication information according to some embodiments of the present disclosure.

[0082] In some embodiments, the MAC CE 710 may have a fixed size and include a single field defined as an I-RNTI field. This field contains the I-RNTI of the MAC entity of the terminal device 120. In some embodiments, the length of the I-RNTI field may be 40 bits, such as Figure 7 As shown in bytes 711-715 in.

[0083] In some embodiments, MAC CE 720 may have a fixed size and consist of a single field defined as a SHORTMAC-I field. This field contains an authentication token to facilitate authentication of terminal device 120 at network device 110. In some embodiments, the length of the SHORTMAC-I field may be 16 bits, such as Figure 7 As shown in bytes 721-722 in.

[0084] return Figure 5 , in box 520, the terminal device 120 sends the first MAC CE and uplink data to the network device 110. In some embodiments, the uplink data may be associated with a small and infrequent data service. In some embodiments, the terminal device 120 may send the first MAC CE, the second MAC CE, and the uplink data to the network device 110. In some alternative embodiments, the terminal device 120 may send the first MAC CE, the uplink data, and the BSR to the network device 110. The BSR may indicate the remaining amount of uplink data to be sent. In some alternative embodiments, the terminal device 120 may send the first MAC CE, the second MAC CE, the uplink data, and the BSR to the network device 110.

[0085] In some embodiments based on the 2-step RACH procedure, the terminal device 120 may send a random preamble sequence, a first MAC CE, and uplink data to the network device 110. In some alternative embodiments, the terminal device 120 may send a random preamble sequence, a first MAC CE, a second MAC CE, and uplink data to the network device 110. In some alternative embodiments, the terminal device 120 may send a random preamble sequence, a first MAC CE, a second MAC CE, and uplink data to the network device 110. In some alternative embodiments, the terminal device 120 may send a random preamble sequence, a first MAC CE, a second MAC CE, uplink data, and a BSR to the network device 110. In some alternative embodiments, the terminal device 120 may send a random preamble sequence, a first MAC CE, a second MAC CE, uplink data, and a BSR to the network device 110.

[0086] In some embodiments based on the 4-step RACH process, the terminal device 120 may send a random preamble sequence to the network device 110, and receive a RAR for the random preamble sequence from the network device 110. According to the reception of the RAR, the terminal device 120 may cause the first identifier to be carried in the first MAC CE.

[0087] In some embodiments, the network device 110 may not configure a contention resolution timer or a RAR window to the terminal device 120. This means that the terminal device 120 only sends uplink data to the network device 110 and does not wait for any contention resolution.

[0088] In some alternative embodiments, the network device 110 may configure the extended contention resolution timer or RAR window to the terminal device 120, as described above in conjunction with Figure 3 Send 305 and Figure 4 In this case, the terminal device 120 may receive contention resolution information from the network device 110.

[0089] In some embodiments based on the 4-step RACH procedure, it can be as follows Figure 8 The third MAC CE is defined in that way to carry contention resolution information. Figure 8 A schematic diagram 800 is shown of an implementation of a MAC CE 810 carrying contention resolution information for a 4-step RACH procedure according to some embodiments of the present disclosure. In some embodiments, the MAC CE 810 may have a fixed size and include a single field defined as a contention resolution identification field. In some embodiments, the length of the contention resolution identification field may be 48 bits, such as Figure 8 As shown in bytes 811-816 in.

[0090] In which Figure 6 In some embodiments where the first MAC CE 610 is shown carrying the first identification and the first authentication information, the contention resolution identification field may include the first 48 bits of the UL CCCH SDU or the first MAC CE, and if the UL CCCHSDU is longer than 48 bits, the field may include the first 48 bits of the UL CCCH SDU.

[0091] In which Figure 7 In some alternative embodiments where the first MAC CE 710 shown carries the first identifier and the second MAC CE 720 carries the first authentication information, the contention resolution identifier field may include the UL CCCH SDU or the first MAC CE 710, and if the UL CCCH SDU is longer than 48 bits, the field includes the first 48 bits of the UL CCCH SDU. For the case of the first MAC CE 710, the most significant bit (MSB) of the field should be set to the padding bit 0.

[0092] In some embodiments based on the 2-step RACH procedure, such as Fig. 9As shown, contention resolution information may be included in a successful RAR. Fig. 9 A schematic diagram 900 is shown illustrating an implementation of a successful RAR 910 carrying contention resolution information for a 2-step RACH procedure according to some embodiments of the present disclosure. In some embodiments, a contention resolution indicator field may be included in the successful RAR 910. In some embodiments, the length of the contention resolution indicator field may be 48 bits, such as Fig. 9 The other fields 917-921 are similar to those in the existing successful RAR, and their details are omitted here.

[0093] In such Figure 6 In some embodiments where the first MAC CE 610 is shown carrying both the first identification and the first authentication information, the contention resolution identification field may include the first 48 bits of the UL CCCH SDU or the first MAC CE, and if the UL CCCHSDU is longer than 48 bits, then the field may include the first 48 bits of the UL CCCH SDU.

[0094] In which Figure 7 In some alternative embodiments where the first MAC CE 710 shown carries the first identifier and the second MAC CE 720 carries the first authentication information, the contention resolution identifier field may include the UL CCCH SDU or the first MAC CE 710, and if the UL CCCH SDU is longer than 48 bits, the field includes the first 48 bits of the UL CCCH SDU. For the case of the first MAC CE 710, the MSB of the field should be set to the padding bit 0.

[0095] The following will refer to Fig.10 The operations after receiving the contention resolution information are further described. Fig.10 Another example communication method 1000 implemented at a terminal device according to some embodiments of the present disclosure is shown. For example, the method 1000 may be implemented in a Figure 1 For the purpose of discussion, reference will be made to Figure 1 Method 1000 is described. It should be understood that method 1000 may include additional blocks not shown and / or may omit some of the blocks shown, and the scope of the present disclosure is not limited in this regard.

[0096] At block 1010, terminal device 120 may determine whether the contention resolution information includes the first identifier. If the contention resolution information includes the first identifier, then at block 1020, terminal device 120 may determine whether second authentication information for network device 110 is received. In some embodiments, the second authentication information may be carried in a fourth MAC CE. Figure 7As shown in MAC CE 720 in FIG. 1 , a fourth MAC CE may be newly defined. In some embodiments, the second authentication information may be carried in the second MAC CE. In this way, the second MAC CE carrying the first authentication information from the terminal device 120 to the network device 110 is reused to carry the second authentication information from the network device 110 to the terminal device 120. Therefore, the corresponding overhead is further reduced.

[0097] If it is determined that the fourth MAC CE is received, the terminal device 120 may determine the reference authentication information (e.g., short MAC-I) for the network device 110 at block 1030. In some embodiments, the terminal device 120 may calculate the short MAC-I value by setting the short MAC-I to the 16 least significant bits of the MAC-I. The MAC-I is calculated by: i) ASN.1 encoded VarSDTMC-Input; ii) K in the UE inactive AS context RRCint key and the previously configured integrity protection algorithm; and iii) setting all input bits for COUNT, BEARER and DIRECTION to binary 1.

[0098] At block 1040, terminal device 120 may verify network device 110 based on the second authentication information and the reference authentication information. In some embodiments, terminal device 120 may match the reference authentication information calculated by itself with the second authentication information received from network device 110. If the reference authentication information matches the second authentication information, terminal device 120 may determine that network device 110 is valid. If the reference authentication information does not match the second authentication information, terminal device 120 may determine that network device 110 is invalid and may discard the received downlink data.

[0099] If it is determined at block 1010 that the contention resolution information does not include the first identifier, the terminal device 120 may perform retransmission of the first MAC CE and the uplink data at block 1050. At block 1060, the terminal device 120 may determine whether the retransmission fails. If it is determined that the retransmission fails, at block 1070, the terminal device 120 may determine whether the number of retransmissions is higher than a predetermined value. In some embodiments, the predetermined value may be broadcast by system information. In some alternative embodiments, the predetermined value may be configured to the terminal device 120 via a dedicated RRC message.

[0100] If the number of retransmissions is less than the predetermined value, the terminal device 120 may perform retransmission again at block 1050. If the number of retransmissions is equal to or greater than the predetermined value, the terminal device 120 may determine that the contention has failed. If the contention has failed, at block 1080, the terminal device 120 may establish a connection with the network device 110 by performing a random access procedure, so that the terminal device 120 is in a connected state.

[0101] In block 1090, the terminal device 120 may transmit uplink data to the network device 110 in the connected state. In some additional embodiments, the terminal device 120 may also transmit information about contention failure associated with the transmission of the uplink data to the network device 110. In some embodiments, the information about contention failure may include the size of the uplink data and the random access procedure used, etc. It should be noted that the information about contention failure is not limited thereto.

[0102] In this way, if contention resolution is unsuccessful, the terminal device 120 can perform small data retransmission. If retransmission fails after a predetermined number of retries, the terminal device 120 can fall back to traditional data transmission, ie, the terminal device 120 only sends data after entering the connected state.

[0103] The following will refer to Fig.11 Operations upon receiving a successful contention resolution are further described. Fig.11 Another example communication method 1100 implemented at a terminal device according to some embodiments of the present disclosure is shown. For example, the method 1100 may be implemented in a Figure 1 For the purpose of discussion, reference will be made to Figure 1 Method 1100 is described. It should be understood that method 1100 may include additional blocks not shown and / or may omit some of the blocks shown, and the scope of the present disclosure is not limited in this regard.

[0104] In box 1110, the terminal device 120 may determine whether the uplink grant information is received. If it is determined that the terminal device 120 receives the uplink grant information, then in box 1120, the terminal device 120 may determine a second identifier of the terminal device 120 for subsequent data transmission. In some embodiments, the second identifier may be a C-RNTI. In some embodiments based on a 4-step RACH process, the second identifier may be determined by using the TC-RNTI in the RAR as the C-RNTI. In some embodiments based on a 2-step RACH process, the second identifier may be determined by using the C-RNTI included in the successful RAR.

[0105] At block 1130, the terminal device 120 may send subsequent uplink data to the network device 110 based on the uplink grant information and the second identification. If there is subsequent UL data or DL ​​data to be sent via the small data transmission, the terminal device 120 will expect to receive an UL grant or DL ​​allocation in the DCI. At block 1140, the terminal device 120 may monitor a downlink channel associated with the terminal device 120 until the time period expires. For example, the downlink channel may be a PDCCH addressed to the C-RNTI.

[0106] In some embodiments, the time period may be a constant value. In some alternative embodiments, the time period may be broadcast in system information. In some alternative embodiments, when the terminal device 120 is in a connected state, the time period may be configured by a dedicated RRC message. For example, the dedicated RRC message may be a RRCRelease or RRCReconfiguration message stored in the UE context.

[0107] In some embodiments, the terminal device 120 may start monitoring the downlink channel in response to receiving uplink grant information, for example, each time uplink grant information for small data transmission is received after the C-RNTI is available. In some alternative embodiments, the terminal device 120 may start monitoring the downlink channel in response to sending subsequent uplink data, for example, each time uplink small data is sent after the C-RNTI is available.

[0108] In some embodiments when the time period expires, the terminal device 120 may stop PDCCH monitoring and release the C-RNTI. In this case, if there is subsequent uplink small data for transmission, the terminal device 120 must initiate the RACH process again. In some embodiments, PDCCH monitoring may also be applied to small data transmission using RRC signaling.

[0109] In some alternative embodiments, the terminal device 120 may use the pre-configured authorization information to perform subsequent data transmission. In some embodiments, the terminal device 120 may receive an indication of the third identifier of the terminal device 120 configured in the connected state and the configuration authorization information in a connection release message from the network device 110, and send subsequent uplink data to the network device 110 based on the configuration authorization information and the third identifier. For example, based on the indication, the terminal device 120 may obtain the corresponding configuration authorization information and the third identifier from the UE context, and use the obtained configuration authorization information and the third identifier to perform small data transmission. The third identifier may be a configuration scheduling RNTI (CS-RNTI).

[0110] In some alternative embodiments, the terminal device 120 may receive new configuration authorization information and a third identifier in a connection release message from the network device 110, and use the received configuration authorization information and the third identifier to perform small data transmission.

[0111] Fig.12 An example communication method 1200 implemented at a network device according to some embodiments of the present disclosure is shown. For example, the method 1200 may be implemented in a Figure 1 For the purpose of discussion, reference will be made to Figure 1 Method 1200 is described. It should be understood that method 1200 may include additional blocks not shown and / or may omit some of the blocks shown, and the scope of the present disclosure is not limited in this regard.

[0112] like Fig.12 As shown, in box 1210, the network device 110 receives a first MAC CE and uplink data from the terminal device 120. The first MAC CE carries a first identifier of the terminal device 120 in an inactive state. In some embodiments based on the 2-step RACH process, the network device 110 may receive the first MAC CE, uplink data, and a random preamble sequence from the terminal device 120. In some embodiments based on the 4-step RACH process, the network device 110 may also receive a random preamble sequence from the terminal device 120 and send a RAR for the random preamble sequence to the terminal device 120.

[0113] At block 1220, the network device 110 sends uplink data to the core network element 131. In this way, small data transmissions can be well performed in the inactive state of the terminal device 120.

[0114] In some embodiments, the first MAC CE may also carry first authentication information for the terminal device 120, and the first identifier and the first authentication information are in different fields of the first MAC CE, such as in combination with Figure 6 In some embodiments, the network device 110 may receive a first MAC CE, uplink data, and a second MAC CE carrying first authentication information for the terminal device 120 from the terminal device 120. The first MAC CE and the second MAC CE may be respectively as follows: Figure 7 The MACCE 710 and MAC CE 720 are defined as shown in FIG.

[0115] Will refer to Fig.13 Describe the operation after receiving the first authentication information. Fig.13 Another example communication method 1300 implemented at a network device according to some embodiments of the present disclosure is shown. For example, the method 1300 may be implemented in a Figure 1 For the purpose of discussion, reference will be made to Figure 1 Method 1300 is described. It should be understood that method 1300 may include additional blocks not shown and / or may omit some of the blocks shown, and the scope of the present disclosure is not limited in this regard.

[0116] At block 1310, network device 110 may determine reference authentication information for terminal device 120. In some embodiments, network device 110 may determine the reference authentication information based on VarSDTMAC-Input as follows:

[0117]

[0118] At block 1320, network device 110 may verify terminal device 120 based on the second authentication information and the reference authentication information. In some embodiments, network device 110 may match the reference authentication information calculated by itself with the first authentication information received from terminal device 120. If the reference authentication information matches the first authentication information, network device 110 may determine that terminal device 120 is valid. In some embodiments, after determining that terminal device 120 is valid, network device 110 may send uplink data to core network element 131.

[0119] If the reference authentication information does not match the first authentication information, network device 110 may determine that terminal device 120 is invalid. In some embodiments, upon determining that terminal device 120 is invalid, network device 110 may discard the received uplink data.

[0120] It is assumed that the network device 110 is a network device that serves the terminal device 120 immediately before the terminal device 120 enters the inactive state (hereinafter also referred to as the last served network device). At block 1330, the network device 110 may determine the second authentication information for the network device 110 based on the first authentication information for the terminal device 120. In some embodiments, for the VarSDTMAC-Input associated with the first authentication information, the network device 110 may determine the second authentication information by using the physical cell identifier (PCI) for the target cell and using the cell identifier (CID) for the source cell. For example, the VarSDTMAC-Input may be modified as follows:

[0121]

[0122] In some alternative embodiments, network device 110 may determine the second authentication information by changing the order of parameters in VarSDTMAC-Input associated with the first authentication information.

[0123] For example, VarSDTMAC-Input can be modified as follows:

[0124]

[0125] In some alternative embodiments, network device 110 may determine the second authentication information by removing one of the parameters in VarSDTMAC-Input associated with the first authentication information.

[0126] For example, VarSDTMAC-Input can be modified as follows:

[0127]

[0128] At block 1340, the network device 110 may send the second authentication information to the terminal device 120. In some embodiments, the network device 110 may generate a fourth MAC CE carrying the second authentication information, and send the contention resolution information and the fourth MAC CE ... Figure 7 The fourth MAC CE is defined as shown in MAC CE 720 in FIG. In some alternative embodiments, the network device 110 may reuse the second MAC CE for transmitting the second authentication information to the terminal device 120.

[0129] In some embodiments where the network device 110 is not the last served network device of the terminal device 120, the second authentication information may be determined by the last served network device and may be sent from the last served network device to the network device 110. For example, the second authentication information may be sent in an Xn message, such as a RETRIEVE UE CONTEXT RESPONSE message or a RETRIEVE UE CONTEXT FAILURE message.

[0130] In some embodiments, the network device 110 may receive the first MAC CE, uplink data, and a BSR from the terminal device 120. The BSR indicates the amount of remaining uplink data to be sent. If there is remaining uplink data, the network device 110 may send uplink grant information to the terminal device 120.

[0131] In some embodiments, the network device 110 may send contention resolution information to the terminal device 120. In some embodiments based on a 4-step RACH process, the contention resolution information may be carried in a third MAC CE. In some embodiments based on a 2-step RACH process, the contention resolution information may be placed in a random access response message. In some alternative embodiments, the network device 110 may send contention resolution information and uplink grant information to the terminal device 120. In some additional embodiments, the network device 110 may receive subsequent uplink data based on the uplink grant information and a second identifier of the terminal device 120 for subsequent data transmission. The second identifier may be a C-RNTI.

[0132] In some alternative embodiments, the network device 110 may send a third identifier of the terminal device 120 configured in the connected state and an indication of the configuration authorization information to the terminal device 120 in a connection release message, and receive subsequent uplink data from the terminal device 120 based on the configuration authorization information and the third identifier. The third identifier may be a CS-RNTI.

[0133] In some embodiments, the network device 110 may send an indication of ending data transmission to the terminal device 120 in a connection release message for initialization of the inactive state of the terminal device 120. For example, if the network device 110 wants to end the small data transmission, the network device 110 may send an indication using an RRC release message so as to put the terminal device 120 in a normal inactive state, i.e., to initialize parameters in the inactive state. For example, the terminal device 120 may suspend a packet data convergence protocol (PDCP) entity and stop PDCCH monitoring.

[0134] In some embodiments, network device 110 may receive downlink data from core network element 131 and send contention resolution information and downlink data to terminal device 120. In some embodiments where contention failure occurs, network device 110 may receive information about contention failure from terminal device 120.

[0135] In some embodiments, if there is no explicit RRC signaling, the PDCP sequence number (SN) and super frame number (HFN) values ​​(also referred to as COUNT values) can be maintained as being counted up at each small data transmission in an inactive state. This will avoid using the same COUNT value more than once under the same security key, thereby ensuring security during small data transmission. In some embodiments where the network device 110 wants to update the security key for the next small data transmission, the network device 110 can send an RRCRelease message with a next hop link counter (NCC).

[0136] Fig.141 is a simplified block diagram of a device 1400 suitable for implementing an embodiment of the present disclosure. The device 1400 can be considered as Figure 1 Another example implementation of the network device 110 or the terminal device 120 is shown. Thus, the device 1400 may be implemented at the network device 110 or the terminal device 120, or as at least a part of the network device 110 or the terminal device 120.

[0137] As shown, the device 1400 includes a processor 1410, a memory 1420 coupled to the processor 1410, a suitable transmitter (TX) and receiver (RX) 1440 coupled to the processor 1410, and a communication interface coupled to the TX / RX 1440. The memory 1410 stores at least a portion of the program 1430. The TX / RX 1440 is used for bidirectional communication. The TX / RX 1440 has at least one antenna to facilitate communication, but in fact the access node mentioned in this application may have several antennas. The communication interface may represent any interface required for communication with other network elements, such as an X2 / Xn interface for bidirectional communication between eNB / gNB, an S1 / NG interface for communication between a mobility management entity (MME) / access and mobility management function (AMF) / SGW / UPF and an eNB / gNB, a Un interface for communication between an eNB / gNB and a relay node (RN), or a Uu interface for communication between an eNB / gNB and a terminal device.

[0138] Assume that program 1430 includes program instructions that, when executed by associated processor 1410, enable device 1400 to operate in accordance with embodiments of the present disclosure, as referred to herein. Figures 1 to 13 As discussed above. The embodiments herein may be implemented by computer software executable by a processor 1410 of the device 1400, or by hardware, or by a combination of software and hardware. The processor 1410 may be configured to implement various embodiments of the present invention. In addition, the combination of the processor 1410 and the memory 1420 may form a processing component 1450 suitable for implementing various embodiments of the present disclosure.

[0139] The memory 1420 may be of any type suitable for the local technology network and may be implemented using any suitable data storage technology, such as, as non-limiting examples, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. Although only one memory 1420 is shown in the device 1400, there may be several physically distinct memory modules in the device 1400. As non-limiting examples, the processor 1410 may be of any type suitable for the local technology network and may include one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The device 1400 may have multiple processors, such as a dedicated integrated circuit chip that is time-slave to a clock that synchronizes a main processor.

[0140] In general, various embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are shown and described as block diagrams, flow charts, or using some other graphical representations, it will be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware, or controllers or other computing devices, or some combination thereof, as non-limiting examples.

[0141] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer executable instructions such as those included in a program module that are executed in a device on a target real or virtual processor to perform the above-referenced Figures 2 to 13 The process or method described. In general, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The functions of program modules can be combined or separated between program modules as needed in various embodiments. The machine executable instructions of program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in both local storage media and remote storage media.

[0142] The program code for executing the disclosed method can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code enables the function / operation specified in the flow chart and / or block diagram to be realized when the program code is executed by the processor or controller. The program code can be executed completely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine, or completely on a remote machine or server.

[0143] The above program code may be contained on a machine-readable medium, which may be any tangible medium that may contain or store a program used by or in conjunction with an instruction execution system, device, or apparatus. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing. More specific examples of machine-readable storage media would include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0144] In addition, although operations are described in a particular order, this should not be understood as requiring the specific order shown or to perform these operations in sequence, or to perform all the operations shown, to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but should be interpreted as descriptions of features peculiar to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0145] Although the disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or actions described above. Instead, the specific features and actions described above are disclosed as example forms of implementing the claims.

Claims

1. A method performed by a user equipment UE, the method comprising: receiving a radio resource control RRC release message from a base station, wherein the RRC release message includes configuration authorization information and a configuration scheduling radio network temporary identifier CS-RNTI; as well as A small data transmission (SDT) is performed based on the configuration authorization information and the CS-RNTI, wherein the SDT is for the UE in an inactive state.

2. The method according to claim 1, further comprising: A Physical Downlink Control Channel (PDCCH) addressed to a Cell Radio Network Temporary Identifier (C-RNTI) of the UE is monitored until a timer expires. The method according to claim 2 , wherein the value of the timer is broadcast in system information.

4. The method according to claim 1, further comprising: A Physical Downlink Control Channel (PDCCH) addressed to a Cell Radio Network Temporary Identifier (C-RNTI) of the UE is monitored until a Radio Resource Control (RRC) release message is received.

5. The method of claim 4, wherein at least one of an uplink grant or a downlink allocation is carried in downlink control information DCI, the DCI being sent in the PDCCH addressed to the C-RNTI, and wherein the SDT is based on at least one of the uplink grant or the downlink allocation.

6. The method according to claim 5, further comprising: Based on the uplink grant, a subsequent uplink transmission is performed.

7. A method performed by a base station, the method comprising: Sending a radio resource control RRC release message to a user equipment UE, wherein the RRC release message includes configuration authorization information and a configuration scheduling radio network temporary identifier CS-RNTI; as well as In a case where the UE remains in an inactive state, a small data transmission SDT is received from the UE based on the configuration authorization information and the CS-RNTI.

8. The method according to claim 7, further comprising: A physical downlink control channel, PDCCH, addressed to a cell radio network temporary identifier, C-RNTI, of the UE is transmitted, wherein the PDCCH addressed to the C-RNTI is monitored by the UE until a timer expires.

9. The method of claim 8, wherein the value of the timer is broadcast in system information.

10. The method according to claim 7, further comprising: A physical downlink control channel (PDCCH) addressed to a cell radio network temporary identifier (C-RNTI) of the UE is transmitted, wherein the PDCCH addressed to the C-RNTI is monitored by the UE until a radio resource control (RRC) release message is received by the UE.

11. The method of claim 8, wherein at least one of an uplink grant or a downlink allocation is carried in downlink control information (DCI), the DCI being sent in the PDCCH addressed to the C-RNTI, and wherein the SDT is based on at least one of the uplink grant or the downlink allocation.

12. The method of claim 11, wherein subsequent uplink transmissions are performed based on the uplink grant.

Images