Method, device and computer storage medium of communication

Abstract

Embodiments of the present disclosure relate to methods, devices and computer readable media for communication. A method comprises a terminal device determines whether one or more DRBs with uplink data to be transmitted support SDT. If the one or more DRBs support the SDT, the terminal device determines whether the uplink data is to be transmitted in the inactive state. If the uplink data is to be transmitted in the inactive state, the terminal device transmits the uplink data to a first network device in the inactive state. Upon receipt of the uplink data, the first network device transmits to a third network device a request for relocating an anchor for a context of the terminal device, the request comprising a first indication as to whether there is remaining data to be transmitted. In this way, an enhanced mechanism for SDT is achieved and lossless transmission for SDT is attained.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the field oftelecommunication, and in particular, to methods, devices and computer storage media ofcommunication for data transmission in an inactive state of a terminal device.BACKGROUND

[0002] Typically, a terminal device in an inactive state may still have small and infrequentdata traffic (also referred to as small data transmission (SDT) hereinafter) to be transmitted.Until the third generation partnership project (3GPP) Release 16, the inactive state cannot support data transmission, and the terminal device has to resume connection (i.e., enter aconnected state) for any downlink and uplink data. Connection setup and subsequentlyrelease to the inactive state happens for each data transmission whatever small andinfrequent the data packets are. This will result in unnecessary power consumption andsignaling overhead.

[0003] In this event, 3GPP Release 17 has approved SDT based on a random accesschannel (RACH) in the inactive state and also approved SDT based on pre-configuredphysical uplink shared channel (PUSCH) resources in the inactive state. Thereby, thesignaling overhead can be reduced. In this case, how to perform SDT has become a hotissue.SUMMARY

[0004] In general, embodiments of the present disclosure provide methods, devices andcomputer storage media for communication.

[0005] In a first aspect, there is provided a method of communication. The methodcomprises: determining, at a terminal device in an inactive state, whether one or more dataradio bearers (DRBs) with uplink data to be transmitted support data transmission in theinactive state; in accordance with a determination that the one or more DRBs support thedata transmission in the inactive state, determining, based on a payload size associated withthe uplink data and a threshold associated with the one or more DRBs, whether the uplinkdata is to be transmitted in the inactive state; and in accordance with a determination thatthe uplink data is to be transmitted in the inactive state, transmitting the uplink data to afirst network device in the inactive state.

[0006] In a second aspect, there is provided a method of communication. The methodcomprises: receiving, at a first network device, uplink data transmitted by a terminal devicein an inactive state; and transmitting, to a third network device, a request for relocating ananchor for a context of the terminal device, the request comprising a first indication as towhether there is remaining data to be transmitted, the third network device maintaining thecontext of the terminal device.

[0007] In a third aspect, there is provided a method of communication. The methodcomprises: receiving, at a second network device and from a terminal device, a first requestfor resuming connection upon cell reselection of the terminal device from a first cell of afirst network device to a second cell of the second network device during data transmissionin an inactive state of the terminal device; and transmitting, to a fourth network devicemaintaining the context of the terminal device, a second request for relocating an anchor fora context of the terminal device.

[0008] In a fourth aspect, there is provided a method of communication. The methodcomprises: receiving, at a third network device and from a first network device, a requestfor relocating an anchor for a context of a terminal device in an inactive state, the requestcomprising a first indication as to whether there is remaining data other than uplink data tobe transmitted, the third network device maintaining the context of the terminal device;determining, based on the first indication, whether the anchor is to be relocated; and inaccordance with a determination that the anchor is not to be relocated, transmitting, to thefirst network device, at least a part of the context for transmission of the uplink data in theinactive state.

[0009] In a fifth aspect, there is provided a method of communication. The methodcomprises: receiving, at a fourth network device and from a second network device, asecond request for relocating an anchor for a context of a terminal device, the fourthnetwork device maintaining the context; in accordance with a determination that the anchoris to be relocated, transmitting, to the second network device, information about sequencenumber and hyper frame number of data packets associated with uplink data to betransmitted; and transmit the data packets to the second network device.

[0010] In a sixth aspect, there is provided a terminal device. The terminal devicecomprises a processor and a memory coupled to the processor. The memory storesinstructions that when executed by the processor, cause the terminal device to perform themethod according to the first aspect of the present disclosure.

[0011] In a seventh aspect, there is provided a first network device. The first networkdevice comprises a processor and a memory coupled to the processor. The memory storesinstructions that when executed by the processor, cause the first network device to performthe method according to the second aspect of the present disclosure.

[0012] In an eighth aspect, there is provided a second network device. The secondnetwork device comprises a processor and a memory coupled to the processor. Thememory stores instructions that when executed by the processor, cause the second networkdevice to perform the method according to the third aspect of the present disclosure.

[0013] In a ninth aspect, there is provided a third network device. The third networkdevice comprises a processor and a memory coupled to the processor. The memory storesinstructions that when executed by the processor, cause the transmitting device to performthe method according to the fourth aspect of the present disclosure.

[0014] In a tenth aspect, there is provided a fourth network device. The fourth networkdevice comprises a processor and a memory coupled to the processor. The memory storesinstructions that when executed by the processor, cause the fourth network device toperform the method according to the fifth aspect of the present disclosure.

[0015] In an eleventh aspect, there is provided a computer readable medium havinginstructions stored thereon. 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 thepresent disclosure.

[0016] In a twelfth aspect, there is provided a computer readable medium havinginstructions stored thereon. 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 thepresent disclosure.

[0017] In a thirteenth aspect, there is provided a computer readable medium havinginstructions stored thereon. The instructions, when executed on at least one processor,cause the at least one processor to perform the method according to the third aspect of thepresent disclosure.

[0018] In a fourteenth aspect, there is provided a computer readable medium havinginstructions stored thereon. The instructions, when executed on at least one processor,cause the at least one processor to perform the method according to the fourth aspect of thepresent disclosure.

[0019] In a fifteenth aspect, there is provided a computer readable medium havinginstructions stored thereon. The instructions, when executed on at least one processor,cause the at least one processor to perform the method according to the fifth aspect of thepresent disclosure.

[0020] Other features of the present disclosure will become easily comprehensiblethrough the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Through the more detailed description of some embodiments of the presentdisclosure in the accompanying drawings, the above and other objects, features andadvantages of the present disclosure will become more apparent, wherein:

[0022] FIG. 1 illustrates an example communication network in which some embodimentsof the present disclosure can be implemented;

[0023] FIG. 2 illustrates a schematic diagram illustrating a process for communicationduring SDT according to embodiments of the present disclosure;

[0024] FIG. 3 illustrates a schematic diagram illustrating a process for communicationupon cell reselection according to embodiments of the present disclosure;

[0025] FIG. 4 illustrates an example method of communication implemented at a terminaldevice in accordance with some embodiments of the present disclosure;

[0026] FIG. 5 illustrates an example method of communication implemented at a firstnetwork device as a current serving network device in accordance with some embodimentsof the present disclosure;

[0027] FIG. 6 illustrates an example method of communication implemented at a secondnetwork device as a new serving network device in accordance with some embodiments ofthe present disclosure;

[0028] FIG. 7 illustrates an example method of communication implemented at a thirdnetwork device as a last serving network device during SDT in accordance with someembodiments of the present disclosure;

[0029] FIG. 8 illustrates an example method of communication implemented at a fourthnetwork device as a last serving network device upon cell reselection in accordance withsome embodiments of the present disclosure; and

[0030] FIG. 9 is a simplified block diagram of a device that is suitable for implementingembodiments of the present disclosure.

[0031] Throughout the drawings, the same or similar reference numerals represent thesame or similar element.DETAILED DESCRIPTION

[0032] Principle of the present disclosure will now be described with reference to someembodiments. It is to be understood that these embodiments are described only for thepurpose of illustration and help those skilled in the art to understand and implement thepresent disclosure, without suggesting any limitations as to the scope of the disclosure.The disclosure described herein can be implemented in various manners other than the onesdescribed below.

[0033] In the following description and claims, unless defined otherwise, all technical andscientific terms used herein have the same meaning as commonly understood by one ofordinary skills in the art to which this disclosure belongs.

[0034] As used herein, the term "terminal device" refers to any device having wireless orwired communication capabilities. Examples of the terminal device include, but notlimited to, user equipment (UE), personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs), portable computers, tablets,wearable devices, internet of things (loT) devices, Internet of Everything (loE) devices,machine type communication (MTC) devices, device on vehicle for V2X communicationwhere X means pedestrian, vehicle, or infrastructure / network, or image capture devicessuch as digital cameras, gaming devices, music storage and playback appliances, or Internetappliances enabling wireless or wired Internet access and browsing and the like. The term "terminal device" can be used interchangeably with a UE, a mobile station, a subscriberstation, a mobile terminal, a user terminal or a wireless device. In addition, the term"network device" refers to a device which is capable of providing or hosting a cell orcoverage where terminal devices can communicate. Examples of a network deviceinclude, but not limited to, a Node B (NodeB or NB), an Evolved NodeB (eNodeB or eNB),a next generation NodeB (gNB), a Transmission Reception Point (TRP), a Remote RadioUnit (RRU), a radio head (RH), a remote radio head (RRH), a low power node such as afemto node, a pico node, and the like.

[0035] In one embodiment, the terminal device may be connected with a first networkdevice and a second network device. One of the first network device and the secondnetwork device may be a master node and the other one may be a secondary node. Thefirst network device and the second network device may use different radio accesstechnologies (RATs). In one embodiment, the first network device may be a first RATdevice and the second network device may be a second RAT device. In one embodiment,the first RAT device is eNB and the second RAT device is gNB. Information related withdifferent RATs may be transmitted to the terminal device from at least one of the firstnetwork device or the second network device. In one embodiment, first information maybe transmitted to the terminal device from the first network device and second informationmay be transmitted to the terminal device from the second network device directly or viathe first network device. In one embodiment, information related with configuration for the terminal device configured by the second network device may be transmitted from thesecond network device via the first network device. Information related withreconfiguration for the terminal device configured by the second network device may betransmitted to the terminal device from the second network device directly or via the firstnetwork device.

[0036] As used herein, the singular forms 'a', 'an' and 'the' are intended to include theplural forms as well, unless the context clearly indicates otherwise. The term 'includes'and its variants are to be read as open terms that mean 'includes, but is not limited to.'The term 'based on' is to be read as 'at least in part based on.' The term 'one embodiment'and 'an embodiment' are to be read as 'at least one embodiment.' The term 'anotherembodiment' is to be read as 'at least one other embodiment.' The terms 'first,' 'second,'and the like may refer to different or same objects. Other definitions, explicit and implicit,may be included below.

[0037] In some examples, values, procedures, or apparatus are referred to as 'best,''lowest,' 'highest,' 'minimum,' 'maximum,' or the like. It will be appreciated that suchdescriptions are intended to indicate that a selection among many used functionalalternatives can be made, and such selections need not be better, smaller, higher, orotherwise preferable to other selections.

[0038] Currently, there are various applications that involve exchange of small andinfrequency data. For example, in some applications of mobile devices, SDT may includetraffic from Instant Messaging (IM) services, heart-beat or keep-alive traffic, for example,from IM or email clients and other services, push notifications in various applications,traffic from wearables (including, for example, periodic positioning information), and / orthe like. In some applications of non-mobile devices, SDT may include sensor data (e.g.,temperature, pressure readings transmitted periodically or in an event-triggered manner inan loT network), metering and alerting information sent from smart meters, and / or the like.

[0039] As mentioned above, 3GPP Release 17 has approved SDT based on a RACH in theinactive state and SDT based on pre-configured PUSCH resources in the inactive state. Inthis case, more details about implementation of SDT need to be studied. In addition, howto support lossless data transmission upon cell reselection during SDT also needs to bestudied.

[0040] In view of this, embodiments of the present disclosure provide a solution forcommunication during SDT. The solution can achieve enhancement on SDT and alsoachieve lossless transmission for SDT during mobility. Principles and implementations ofthe present disclosure will be described in detail below with reference to the figures.Example of CommunicationNetwork

[0041] FIG. 1 illustrates a schematic diagram of an example communication network 100in which some embodiments of the present disclosure can be implemented. As shown inFIG. 1, the communication network 100 may include a first network device 110, a secondnetwork device 120, a third network device 130, a fourth network device 140 and a terminaldevice 150. The terminal device 150 may be served by any of the first network device 110,the second network device 120, the third network device 130 and the fourth network device140. It is to be understood that the number of devices in FIG. 1 is given for the purpose ofillustration without suggesting any limitations to the present disclosure. Thecommunication network 100 may include any suitable number of network devices and / orterminal devices adapted for implementing implementations of the present disclosure.

[0042] As shown in FIG. 1, the first network device 110 may communicate with theterminal device 150 via a channel such as a wireless communication channel. Similarly,each of the second, third and fourth network devices 120, 130 and 140 may alsocommunicate with the terminal device 150 via a channel such as a wireless communicationchannel. The first, second, third and fourth network devices 110, 120, 130 and 140 maycommunicate with each other.

[0043] The communications in the communication network 100 may conform to anysuitable standards including, but not limited to, Global System for Mobile Communications(GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), WidebandCode Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA),GSM EDGE Radio Access Network (GERAN), Machine Type Communication (MTC) andthe like. Furthermore, the communications may be performed according to any generationcommunication protocols either currently known or to be developed in the future.Examples of the communication protocols include, but not limited to, the first generation(1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourthgeneration (4G), 4.5G, the fifth generation (5G) communication protocols.

[0044] Each of the first, second, third and fourth network devices 110, 120, 130 and 140may have at least one cell (not shown). In some scenarios, in an earlier stage, the terminaldevice 150 is served by the third network device 130 in a connected state, and the thirdnetwork device 130 maintains a context for the terminal device 150. In some cases, thethird network device 130 may instruct the terminal device 150 to enter into an inactive state,and then the terminal device 150 may enter into the inactive state. During the terminaldevice 150 is moving toward the first network device 110, the terminal device 150 isswitched to be served by the first network device 110. In this case, the third networkdevice 130 may be the last serving network device maintaining the context for the terminaldevice 150. In some embodiments, the first network device 110 may be the last servingnetwork device maintaining the context for the terminal device 150.

[0045] In some other scenarios, due to the movement of the terminal device 150, theterminal device 150 may perform a cell reselection from one cell to another cell during theinactive state. For example, the terminal device 150 may perform the cell reselection froma first cell of the first network device 110 to a second cell of the second network device 120during the inactive state. For convenience, assuming that upon the cell reselection, thefourth network device 140 is the last serving network device maintaining the context for theterminal device 150. In some embodiments, the fourth network device 140 may be thefirst network device 110 per se. In some embodiments, the fourth network device 140may be the third network device 130 per se.

[0046] Embodiments of the present application provide improve solutions forcommunication in these scenarios. It will be described below with reference to FIGs. 2and 3. FIG. 2 illustrates a schematic diagram illustrating a process 200 for communicationduring SDT according to embodiments of the present disclosure. For the purpose ofdiscussion, the process 200 will be described with reference to FIG. 1. The process 200may involve the terminal device 150 and the first and third network devices 110 and 130 asillustrated in FIG. 1. In this example, assuming that the terminal device 150 is currentlyserved by the first network device 110 and is in an inactive state.DECISION AND PERFORMANCE OF SDT

[0047] As shown in FIG. 2, if there is new uplink data from one or more DRBs, theterminal device 120 determines 201 whether the one or more DRBs support SDT. In someembodiments, the terminal device 120 may receive, from the first network device 110, asignaling indicating whether SDT is allowed by the first network device 110 for a DRB,and determine, based on the received signaling, whether the one or more DRBs supportSDT. In some embodiments, the signaling may be an RRCReconfiguration message.Alternatively, in some embodiments, the signaling may be an RRCRelease message. Ofcourse, any other suitable signaling is also feasible.

[0048] If all the DRBs support SDT, the terminal device 120 determines 202, based on apayload size associated with the uplink data and a threshold associated with the one ormore DRBs, whether the uplink data is to be transmitted in the inactive state. In someembodiments, the threshold may be configured by the first network device 110. Forexample, the threshold may be broadcasted in a system message from the first networkdevice 110. As another example, the threshold may be configured to the terminal device150 dedicatedly using a RRC message e.g. a RRCReconfiguration message or aRRCRelease message.

[0049] In some embodiments, the threshold may be configured per terminal device. Forexample, a first threshold size is configured for the terminal device 150. In someembodiments, the terminal device 150 may determine a total payload size of the uplink data.If determining that the total payload size is less than the first threshold size, the terminaldevice 150 may determine that the uplink data is to be transmitted in the inactive state.

[0050] In some embodiments, the threshold may be configured per DRB. For example, asecond threshold size is configured for a DRB. In some embodiments, only one DRB maybe allowed for SDT. Of course, more than one DRB may also be allowed for SDT. Insome embodiments, the second threshold size is commonly set for each of the DRBs. Inthese embodiments, the terminal device 150 may determine a payload size of data in theuplink data corresponding to each of the DRBs. If the payload size is less than the secondthreshold size, the terminal device 150 may determine that the uplink data is to betransmitted in the inactive state. In some alternative embodiments, the second thresholdsize is independently set for each of the DRBs. In these embodiments, the terminal device150 may determine a payload size of data in the uplink data corresponding to each of theDRBs. If the payload size is less than the corresponding second threshold size, theterminal device 150 may determine that the uplink data is to be transmitted in the inactivestate.

[0051] If determining that the uplink data is to be transmitted in the inactive state, theterminal device 150 transmits 203 the uplink data to the first network device 110. In someembodiments, the terminal device 150 may perform a RACH procedure such as a 4-step or2-step RACH procedure to transmit the uplink data. For example, if the terminal device150 makes a decision on performing RACH based SDT, the terminal device 150 mayresume at least DRBs with the uplink data, and initiate a 4-step or 2-step RACH procedurewith the uplink data multiplexed with RRC Resume Request message in message 3 (msg 3)of the 4-step RACH procedure or message A (msg A) of the 2-step RACH procedure.

[0052] In some embodiments, the terminal device 150 may receive a configuration about abandwidth part (BWP) for SDT from the first network device 110, and perform a RACHprocedure based on the BWP configuration for transmission of the uplink data. In thisway, traffic load on an initial BWP can be significantly alleviated. In some embodiments,one or more BWPs other than the initial BWP may be dedicatedly configured for SDT.

[0053] In some embodiments, the BWP configuration can be broadcasted in a systemmessage from the first network device 110. Alternatively, the BWP configuration can beconfigured to the terminal device 150 via a dedicated signaling. For example, thededicated signaling may be RRCRelease message. Of course, any other suitable signalingis also feasible.

[0054] In some embodiments, the terminal device 150 may also transmit the uplink datavia a pre-configured uplink resource for SDT (also referred to as CG based SDT). Itshould be noted that any other suitable ways may also be used for transmission of theuplink data, and the present application does not make limitation for this.

[0055] In some embodiments, the terminal device 150 may also transmit an indication asto whether remaining data other than the uplink data is to be transmitted. In someembodiments, the terminal device 150 may transmit a buffer status report (BSR) to indicatewhether the remaining data presents. In this way, it is helpful for a network device tomake decision on whether to perform anchor relocation for a context of the terminal device150. For example, the terminal device 150 may transmit the indication in msg 3 of the4-step RACH procedure or msg A of the 2-step RACH procedure.Processing ofAnchor Relocationfor SDT

[0056] Upon receipt of the uplink data transmitted by the terminal device 150, the firstnetwork device 110 may transmit 204, to the third network device 130, a request for relocating an anchor for a context of the terminal device 150. The third network device130 is the last serving network device maintaining the context. For example, the firstnetwork device 110 may determine whether it per se is a new network device other than thelast serving network device. If determining that it per se is the new network device, thefirst network device 110 may transmit the request to the third network device 130 servingas the last serving network device.

[0057] For example, the first network device 110 may transmit a RETRIEVE UECONTEXT REQUEST message to the third network device 130. In some embodiments,the request comprises a first indication as to whether there is remaining data to betransmitted. In other words, the first indication indicates whether there is a one-shot SDT.In this way, whether there is the remaining data to be transmitted can be explicitly indicatedto the last serving network device. For example, the first indication may be one bit. Thefirst value of the bit may indicate that there is the remaining data, and the second value ofthe bit may indicate that there is no remaining data. Of course, any other suitable ways arealso feasible.

[0058] In some alternative embodiments, the indication may comprise user plane transportnetwork layer (UP TNL) information for downlink transmission. With the information,the indication indicates that there is no remaining data. In some alternative embodiments,the indication may comprise the BSR from the terminal device 150 for implicitly indicatingwhether there is the remaining data to be transmitted.

[0059] Upon receipt of the request for relocating the anchor, the third network device 130determines 205 whether the anchor is relocated based on the first indication in the request.

[0060] In some embodiments, if the first indication indicates that there is no remainingdata, i.e., this is a one-shot SDT, the third network device 130 may decide whether torelocate the context or not. In some embodiments, if the first indication indicates thatthere is the remaining data, i.e., this is not a one-shot SDT, the third network device 130may relocate the anchor to the first network device 110. The reason is that for thenon-one-shot SDT, the msg4 of the 4-step RACH procedure or msg B of the 2-step RACHprocedure should be generated by the new network device using SRB1, thus the context isrequired.

[0061] If anchor relocation is performed, the third network device 130 may transmit aresponse to the request comprising the context to the first network device 110. Forexample, the third network device 130 may transmit a RETRIEVE UE CONTEXTRESPONSE message to the first network device 110.

[0062] If anchor relocation is not performed, the third network device 130 may transmit206, to the first network device 110, at least a part of the context for transmission of theuplink data in the inactive state. Then, the first network device 110 may transmit 207 datapackets associated with the uplink data to the third network device 130 based on the part ofthe context, and release 208 the context of the terminal device 150.

[0063] In some embodiments, the third network device 130 may transmit, to the firstnetwork device 110, a message comprising a connection release message to be transmittedto the terminal device 150, UP TNL information for uplink transmission and a part of thecontext comprising at least radio link control (RLC) configuration of the terminal device150. For example, the third network device 130 may feedback a RETRIEVE UECONTEXT FAILURE message with an encapsulated RRCRelease message, UP TNLinformation for uplink data, and part of the context with at least RLC configuration of theterminal device 150. Then the first network device 110 may establish RLC entityaccording to the RLC configuration. After RLC processing, the first network device 110may transmit one or more UL PDCP PDUs to the third network device 130. The thirdnetwork device 130 may perform service data adaptation protocol (SDAP) and PDCPprocessing of the uplink data and then transmit it to the core network. If there is furtherdownlink (DL) data, the third network device 130 may perform SDAP and PDCPprocessing of the further downlink data and then transmit one or more DL PDCP PDUs tothe first network device 110. The first network device then transmits the DL data togetherwith the RRCRelease message to the terminal device 150. The first network device 110also release the part of the context.

[0064] In some embodiments, the third network device 130 may transmit, to the firstnetwork device 110, a response to the request, the response comprising the context and asecond indication that the anchor is not relocated. For example, the third network device130 may feedback a RETRIEVE UE CONTEXT RESPONSE message with the contextand the second indication. As another example, the third network device 130 mayfeedback a RETRIEVE UE CONTEXT RESPONSE message with the context and the UPTNL information for uplink transmission. If the response implies that the anchor is notrelocated, the first network device 110 may establish RLC entities according to the context,and transmit one or more UL PDCP PDUs to the third network device 130 after RLCprocessing. If DL data is received by the third network device 130, the third networkdevice 130 may transmit DL PDCP PDUs after SDAP and PDCP processing to the firstnetwork device 110. The first network device 110 send DL data to the terminal device 150after RLC and MAC processing.

[0065] In some embodiments, the first network device 110 may establish RLC, PDCPand SDAP entities for the one or more DRBs, and transmit the UL data to the third networkdevice 130 after RLC, PDCP and SDAP processing. If DL data is received by the thirdnetwork device 130, the third network device 130 may transmit the DL data to the firstnetwork device 110.

[0066] The first network device 110 may generate a RRC message such as RRCRelease message and transmit 209 the RRC message to the terminal device 150 with or withoutdownlink data associated with the uplink data. In some embodiments, the downlink datamay be transmitted to the terminal device 150 together with the RRC message in msg 4 of a4-step RACH procedure or msg B of a 2-step RACH procedure. The first network device110 shall releases the context after the SDT procedure.Processing of New Uplink TransmissionDuring SDT

[0067] During SDT, if there is a new uplink transmission (also referred to as a furtheruplink transmission herein), the terminal device 150 may process the further uplinktransmission according to whether it is new uplink data or signaling and whether a DRB(also referred to as a further DRB) with the new uplink data supports SDT.

[0068] In some embodiments, the terminal device 150 may determine 210 whether furtheruplink transmission comprises an uplink signaling. If determining that the further uplinktransmission comprises the uplink signaling, the terminal device 150 may suspend 212DRBs associated with the terminal device 150, and perform 213 the further uplinktransmission in a connected state based on a RACH procedure. For example, the terminaldevice 150 may reset a media access control (MAC) entity, suspend all the DRBs that arenot suspended, initiate a RRC Resume procedure for normal data transmission. Uponreceipt of a RRCResume message from the first network device 110, the terminal device150 may perform RLC re-establishment and PDCP re-establishment as indicated in theRRCResume message. In some embodiments, the terminal device 150 may transmit, tothe first network device 110, a PDCP status report for a DRB in an acknowledge mode (AM)of the RLC layer. In some embodiments, the terminal device 150 may also perform, in theconnected state and based on the RACH procedure, transmission of data in the uplink datathat is not transmitted successfully. In some embodiments, the terminal device 150 maycannel the transmission of data in the uplink data that is not transmitted successfully.

[0069] If determining that the further uplink transmission does not comprise the uplinksignaling, i.e., the further uplink transmission comprises further uplink data, the terminaldevice 150 may determine 211 whether the further DRB with the further uplink data isdifferent from each of the current DRBs and the further DRB supports SDT, and ifdetermining that the further DRB does not support SDT, the terminal device 150 maysuspend 212 DRBs associated with the terminal device 150, and perform 213 the furtheruplink transmission in a connected state based on a RACH procedure. For example, theterminal device 150 may reset a MAC entity, suspend all the DRBs that are not suspended,initiate a RRC Resume procedure for normal data transmission. Upon receipt of aRRCResume message from the first network device 110, the terminal device 150 mayperform RLC re-establishment and PDCP re-establishment as indicated in the RRCResumemessage. In some embodiments, the terminal device 150 may transmit, to the firstnetwork device 110, a PDCP status report for a DRB in an AM of the RLC layer. In someembodiments, the terminal device 150 may also perform, in the connected state and basedon the RACH procedure, transmission of data in the uplink data that is not transmittedsuccessfully. In some embodiments, the terminal device 150 may cannel the transmissionof data in the uplink data that is not transmitted successfully.

[0070] In some embodiments, if determining that the further DRB is different from eachof the current DRBs and supports SDT, the terminal device 150 may determine 214 whetherthe further uplink transmission is to be performed in the inactive state. In someembodiments, the terminal device 150 may determine whether the further uplinktransmission and transmission of data in the uplink data that is not transmitted successfully(also referred to as unfinished data transmission herein) fulfills the condition for SDT.Similar to decision on SDT for the uplink data, the terminal device 150 may determine atotal payload size of the further uplink transmission and the unfinished data transmissionand if determining that the total payload size is less than a threshold, the terminal device150 may determine that the further uplink transmission is to be performed in the inactivestate. Other details are omitted for concise here.

[0071] If determining that the further uplink transmission is to be performed in theinactive state, the terminal device 150 may perform 215 the further uplink transmission inthe inactive state. In some embodiments, the terminal device 150 may resume the furtherDRB, reset MAC entity, release MAC cell group configuration, perform RLCre-establishment for DRBs not suspended, and initiate a SDT procedure for performing thefurther uplink transmission. In some embodiments, the terminal device 150 may alsoperform, in the inactive state, the transmission of data in the uplink data that is nottransmitted successfully. In some embodiments, the terminal device 150 may cannel thetransmission of data in the uplink data that is not transmitted successfully.

[0072] If determining that the further uplink transmission is not to be performed in theinactive state, the terminal device 150 may suspend DRBs associated with the terminaldevice 150, and perform the further uplink transmission in a connected state based on aRACH procedure. In some embodiments, the terminal device 150 may perform thefurther uplink transmission upon entrance of an idle state. Alternatively, the terminaldevice 150 may reset the MAC entity and release MAC cell group configuration for theMAC entity, release all RLC and PDCP entities, and initiate RRC establishment procedurefor the further uplink transmission by transmitting a RRC setup Request message to the firstnetwork device 110. Of course, the terminal device 150 may also initiate a RRC Resumeprocedure for normal data transmission for the further uplink transmission after the currentSDT transmission.

[0073] In some alternative embodiments, during SDT, no matter it is a RACH based SDT,CG based SDT or subsequent SDT, if there is new uplink data from a DRB that does notsupport (i.e., is not configured with) SDT, or if there is new uplink signaling arriving, or ifthere is new uplink data from other DRBs than the current DRBs, the terminal device 150may perform the further uplink transmission upon entrance of an idle state. Alternatively,the terminal device 150 may reset the MAC entity and release MAC cell groupconfiguration for the MAC entity, release all RLC and PDCP entities, and initiate RRCestablishment procedure for the further uplink transmission by transmitting a RRC setupRequest message to the first network device 110. Of course, the terminal device 150 mayalso initiate a RRC Resume procedure for normal data transmission for the further uplinktransmission after the current SDT transmission.

[0074] In this way, lossless transmission in case of new uplink transmission from otherDRB can be supported.Processing upon CellReselectionduring SDT

[0075] When the terminal device 150 is performing SDT, no matter it is a RACH basedSDT, CG based SDT or subsequent SDT, upon cell reselection from a current cell (alsoreferred to as a first cell herein) to a new cell (also referred to as a second cell herein)happens, the terminal device may check whether the second cell supports SDT, that is,whether SDT is allowed in the second cell. It will be described in detail with reference toFIG. 3. FIG. 3 illustrates a schematic diagram illustrating a process 300 forcommunication upon cell reselection according to embodiments of the present disclosure.For the purpose of discussion, the process 300 will be described with reference to FIG. 1.The process 300 may involve the terminal device 150 and the second and fourth networkdevices 120 and 140 as illustrated in FIG. 1. In this example, assuming that a serving cellof the terminal device 150 in the inactive state is reselected from the first cell of the firstnetwork device 110 to the second cell of the second network device 120 and the fourthnetwork device 140 is the last serving network device maintaining a context of the terminaldevice 150.New CellSupporting SDT

[0076] As shown in FIG. 3, the terminal device 150 may determine 301 whether SDT canbe performed in the second cell. In some embodiments, the terminal device 150 maydetermine whether the second cell supports SDT and whether the condition for SDT issatisfied. If the terminal device 150 determines that the second cell supports SDT and thecondition for SDT is satisfied, the terminal device 150 may determine that SDT can beperformed in the second cell. For example, the terminal device 150 may determinewhether the second cell supports SDT based on a system message from the second networkdevice 120. As a further example, the terminal device 150 may determine whether thecondition for SDT is satisfied based on a payload size of data in the uplink data that is nottransmitted successfully. This is merely an example, and the present application does notmake limitation for this.

[0077] If determining that SDT can be performed in the second cell, the terminal device150 may maintain 302 in the inactive state. In some embodiments, while maintaining inthe inactive state, the terminal device 150 may reset a MAC entity of a MAC layer of theterminal device 150. In some embodiments, the terminal device 150 may release a MACcell group configuration for the MAC entity. In some embodiments, the terminal device150 may perform a re-establishment of a RLC entity of a RLC layer of the terminal device150 for DRBs associated with the terminal device 150 that are not suspended. In someembodiments, the terminal device 150 may perform a re-establishment of a PDCP entity ofa PDCP layer of the terminal device 150 for the DRBs associated with the terminal device150 that are not suspended.

[0078] Then the terminal device 150 may transmit 303 the uplink data to the second cellin the inactive state. In some embodiments, the terminal device 150 may initiate SDTprocedure in the second cell as that in the first cell (i.e., the first network device 110)described previously. For example, the terminal device 150 may transmit a request (alsoreferred to as a first request herein) for resuming connection to the second network device120. As an example, the terminal device 150 may transmit a RRC Resume Requestmessage. In some embodiments, the terminal device 150 may transmit, to the second cell,a PDCP status report for a RLC AM DRB.

[0079] Upon receipt of the first request from the terminal device 150, the second networkdevice 120 may determine whether it per se is a new network device serving the terminaldevice 150. If determining that it per se is the new network device, the second networkdevice 120 may transmit 306, to the fourth network device 140, a second request forrelocating an anchor for the context of the terminal device 150. In some embodiments, thesecond request may comprise UP TNL information for uplink and downlink transmission(i.e., UP TLN information for data forwarding). For example, the second network device120 may transmit a RETREVE UE CONTEXT REQUEST message comprising the UPTNL information for data forwarding. Of course, any other suitable messages are alsofeasible.

[0080] Upon receipt of the second request for relocating the anchor, the fourth networkdevice 140 may determine 307 whether the anchor is to be relocated. If the fourthnetwork device 140 determines that the anchor is to be relocated, that is, decides to performanchor relocation, the fourth network device 140 may transmit 308, to the second networkdevice 120, information about SN and HFN of data packets associated with the uplink data.In other words, the fourth network device 140 may transmit the uplink and downlink PDCPSN and HFN status information, i.e., the SN and HFN information concerning uplink datapackets from the terminal device 150 that has not been transmitted to the core network anddownlink data packets from the core network that has not been transmitted to the terminaldevice 150 successfully.

[0081] In some embodiments, the fourth network device 140 may transmit the SN andHFN information in a response to the second request to the second network device 120, theresponse comprising the context. For example, the fourth network device 140 maytransmit the SN and HFN information in the RETRIEVE UE CONTEXT RESPONSEmessage. In some alternative embodiments, the fourth network device 140 may transmit the SN and HFN information in a message dedicated for transmission of the information.For example, the fourth network device 140 may transmit a RETRIEVE UE CONTEXTRESPONSE message comprising the context, and also transmit the SN and HFNinformation in a SN STATUS TRANSFER message. Of course, any other suitablemessages are also feasible, and the present application is limited to the above examples.

[0082] In some embodiments where the second request for relocating the anchor does notcomprise UP TNL information for data forwarding, the fourth network device 140 maytransmit, to the second network device 120, a request (also referred to as a third requestherein) for obtaining the UP TNL information for data forwarding. In some embodiments,the third request may comprise a PDU session identity (ID) associated with the UP TNLinformation for data forwarding. In some alternative or additional embodiments, the thirdrequest may comprise a DRB ID list associated with the UP TLN information for dataforwarding.

[0083] In some embodiments, the third request may be comprised in a response to thesecond request. For example, the third request may be comprised in the RETRIEVE UECONTEXT RESPONSE message. Of course, the third request also can be transmitted inany other suitable messages.

[0084] Upon receipt of the third request, the second network device 120 may transmit theUP TNL information for data forwarding to the fourth network device 140. In someembodiments where the third request comprises the PDU session ID, the second networkdevice 120 may transmit the UP TNL information for the PDU session ID to the fourthnetwork device 140. In some embodiments where the third request comprises the DRB IDlist, the second network device 120 may transmit the UP TNL information for the DRB IDlist to the fourth network device 140. In some embodiments, the second network device120 may transmit the UP TNL information for data forwarding to the fourth network device140 via a XN-U ADDRESS INDICATION message. Of course, any other suitablemessages are also feasible.

[0085] Then the fourth network device 140 may perform 309 a data forwarding procedureto forward the data packets from the fourth network device 140 to the second networkdevice 120. The data packets may involve uplink data packets from the terminal device150 that has not been transmitted to the core network and downlink data packets from thecore network that has not been transmitted to the terminal device 150 successfully.

[0086] If the fourth network device 140 determines that the anchor is not to be relocated,that is, the fourth network device 140 decides not to perform anchor relocation, the fourthnetwork device 140 may transmit, to the second network device 120, at least a part of thecontext. Accordingly, the second network device 120 may transmit data packetsassociated with the uplink data to the fourth network device 140 based on the part of thecontext, and release the context of the terminal device 150.

[0087] In some embodiments, the fourth network device 140 may transmit, to the secondnetwork device 120, a message comprising a connection release message to be transmittedto the terminal device 150, UP TNL information for uplink transmission and a part of thecontext comprising at least RLC configuration of the terminal device 150. For example,the fourth network device 140 may feedback a RETRIEVE UE CONTEXT FAILUREmessage with encapsulated RRCRelease message, UP TNL information, and part of thecontext with at least RLC configuration of the terminal device 150. Accordingly, thesecond network device 120 may forward the RRCRelease message to the terminal device150. Then the second network device 120 may establish RLC entity according to the RLCconfiguration. After RLC processing, the second network device 120 may transmit one ormore UL PDCP PDUs to the fourth network device 140. Then the second network device120 may release the context. The fourth network device 140 may perform SDAP andPDCP processing of the uplink data and then transmit it to the core network. If there isfurther downlink data, the fourth network device 140 may perform SDAP and PDCPprocessing of the further downlink data and then transmit one or more DL PDCP PDUs tothe second network device 120.

[0088] In some embodiments, the fourth network device 140 may transmit, to the secondnetwork device 120, a response to the request, the response comprising the context and asecond indication that the anchor is not relocated. For example, the third network device130 may feedback a RETRIEVE UE CONTEXT RESPONSE message with the contextand the second indication. As another example, the fourth network device 140 mayfeedback a RETRIEVE UE CONTEXT RESPONSE message with the context and the UPTNL information for uplink transmission. If the response implies that the anchor is notrelocated, the second network device 120 may establish RLC entities according to thecontext, and transmit one or more UL PDCP PDUs to the fourth network device 140 afterRLC processing.

[0089] The second network device 120 may generate a RRC message such asRRCRelease message and transmit the RRC message to the terminal device 150 with orwithout downlink data associated with the uplink data. In some embodiments, thedownlink data may be transmitted to the terminal device 150 together with the RRCmessage in msg 4 of a 4-step RACH procedure or msg B of a 2-step RACH procedure.New CellNot Supporting SDT

[0090] If determining that the second cell does not support SDT, the terminal device 150may suspend 310 DRBs associated with the terminal device 150 while maintaining in theinactive state. Then the terminal device 150 may perform 311 a RACH procedure fortransmission of the uplink data in a connected state. For example, the terminal device 150may maintain in the inactive state and reset a MAC entity, suspend all the DRBs notsuspended, and initiate a RRC Resume procedure for normal data transmission. Uponreceipt of a RRCResume message from the second network device 120, the terminal device150 may perform a RLC re-establishment, PDCP re-establishment for the DRBs asindicated in the RRCResume message.

[0091] Upon receipt of the first request from the terminal device 150, the second networkdevice 120 may determine whether it per se is a new network device serving the terminaldevice 150. If determining that it per se is the new network device, the second networkdevice 120 may transmit 312, to the fourth network device 140, a second request for relocating an anchor for the context of the terminal device 150. In some embodiments, thesecond request may comprise UP TNL information for uplink and downlink transmission(i.e., UP TLN information for data forwarding). For example, the second network device120 may transmit a RETREVE UE CONTEXT REQUEST message comprising the UPTNL information for data forwarding. Of course, any other suitable messages are alsofeasible.

[0092] Upon receipt of the second request for relocating the anchor, the fourth networkdevice 140 may transmit 313, to the second network device 120, information about SN andHFN of data packets associated with the uplink data. In other words, the fourth networkdevice 140 may transmit the uplink and downlink PDCP SN and HFN status information,i.e., the SN and HFN information concerning uplink data packets from the terminal device150 that has not been transmitted to the core network and downlink data packets from thecore network that has not been transmitted to the terminal device 150.

[0093] In some embodiments, the fourth network device 140 may transmit the SN andHFN information in a response to the second request to the second network device 120, theresponse comprising the context. For example, the fourth network device 140 maytransmit the SN and HFN information in the RETRIEVE UE CONTEXT RESPONSEmessage. In some alternative embodiments, the fourth network device 140 may transmit the SN and HFN information in a message dedicated for transmission of the information.For example, the fourth network device 140 may transmit a RETRIEVE UE CONTEXTRESPONSE message comprising the context, and also transmit the SN and HFNinformation in a SN STATUS TRANSFER message. Of course, any other suitablemessages are also feasible, and the present application is limited to the above examples.

[0094] In some embodiments where the second request for relocating the anchor does notcomprise UP TNL information for data forwarding, the fourth network device 140 maytransmit, to the second network device 120, a request (also referred to as a third requestherein) for obtaining the UP TNL information for data forwarding. In some embodiments,the third request may comprise a PDU session identity (ID) associated with the UP TLNinformation for data forwarding. In some alternative or additional embodiments, the thirdrequest may comprise a DRB ID list associated with the UP TLN information for data forwarding.

[0095] In some embodiments, the third request may be comprised in a response to thesecond request. For example, the third request may be comprised in the RETRIEVE UECONTEXT RESPONSE message. Of course, the third request also can be transmitted inany other suitable messages.

[0096] Upon receipt of the third request, the second network device 120 may transmit theUP TNL information for data forwarding to the fourth network device 140. In someembodiments where the third request comprises the PDU session ID, the second networkdevice 120 may transmit the UP TNL information for the PDU session ID to the fourthnetwork device 140. In some embodiments where the third request comprises the DRB IDlist, the second network device 120 may transmit the UP TNL information for the DRB IDlist to the fourth network device 140. In some embodiments, the second network device120 may transmit the UP TNL information for data forwarding to the fourth network device140 via a XN-U ADDRESS INDICATION message. Of course, any other suitablemessages are also feasible.

[0097] Then the fourth network device 140 may perform 314 a data forwarding procedureto forward the data packets from the fourth network device 140 to the second networkdevice 120. The data packets may involve uplink data packets from the terminal device150 that has not been transmitted to the core network and downlink data packets from thecore network that has not been transmitted to the terminal device 150.

[0098] With the process shown in FIG. 3, lossless transmission upon cell reselectionduring SDT can be supported.

[0099] It should be note that actions shown in FIGs. 2 and 3 are not always necessary forimplementing embodiments of the present disclosure, and more or less actions may beadapted as needed. Corresponding to the processes described in FIGs. 2 and 3,embodiments of the present disclosure provide methods of communication implemented ata terminal device and network devices. These methods will be described below withreference to FIGs. 4 to 8.Examples for Methods of Communication

[00100] FIG. 4 illustrates an example method 400 of communication implemented at aterminal device in accordance with some embodiments of the present disclosure. Forexample, the method 400 may be performed at the terminal device 150 as shown in FIG. 1.For the purpose of discussion, in the following, the method 400 will be described withreference to FIG. 1. It is to be understood that the method 400 may include additionalblocks not shown and / or may omit some blocks as shown, and the scope of the presentdisclosure is not limited in this regard.

[00101] At block 410, the terminal device 150 determines whether one or more DRBs withuplink data to be transmitted support data transmission in an inactive state of the terminaldevice 150. That is, the terminal device 150 determines whether the one or more DRBssupport SDT.

[00102] If the one or more DRBs support the data transmission in the inactive state, atblock 420, the terminal device 150 determines whether the uplink data is to be transmittedin the inactive state based on a payload size associated with the uplink data and a thresholdassociated with the one or more DRBs. In some embodiments, the terminal device 150may determine a total payload size of the uplink data, and if determining that the totalpayload size is less than a first threshold size, the terminal device 150 may determine thatthe uplink data is to be transmitted in the inactive state.

[00103] In some alternative embodiments, the terminal device 150 may determine apayload size of data in the uplink data corresponding to each of the one or more DRBs, andif the payload size is less than the second threshold size, the terminal device 150 maydetermine that the uplink data is to be transmitted in the inactive state. In some additionalor alternative embodiments, the second threshold size is set in association with each of theDRBs.

[00104] If uplink data is determined to be transmitted in the inactive state, at block 430, theterminal device 150 transmits the uplink data to the first network device 110 in the inactivestate. In some embodiments, the terminal device 150 may receive, from the first networkdevice 110, a configuration about a BWP for the data transmission in the inactive state, andperform, based on the configuration, a RACH procedure for transmission of the uplink data.In some embodiments, the terminal device 150 may transmit, to the first network device110, an indication as to whether remaining data other than the uplink data is to betransmitted.

[00105] In some embodiments, the terminal device 150 may determine whether the datatransmission in the inactive state can be performed in the second cell upon cell reselectionfrom a first cell of the first network device 110 to the second cell of a second networkdevice 120. In some embodiments, if determining that the data transmission in theinactive state can be performed in the second cell, the terminal device 150 may maintain inthe inactive state, and transmit the uplink data to the second cell in the inactive state.

[00106] In some additional or alternative embodiments, the terminal device 150 mayperform, while maintaining in the inactive state, at least one of the following: a reset of aMAC entity of a MAC layer of the terminal device 150; a release of a MAC cell groupconfiguration for the MAC entity; a re-establishment of a RLC entity of a RLC layer of theterminal device 150 for DRBs associated with the terminal device 150 that are notsuspended; or a re-establishment of a PDCP entity of a PDCP layer of the terminal device150 for the DRBs associated with the terminal device that are not suspended. In someembodiments, the terminal device 150 may further transmit, to the second cell, a PDCPstatus report for a DRB in an AM of the RLC layer.

[00107] In some embodiments, if determining that the data transmission in the inactivestate cannot be performed in the second cell, the terminal device 150 may suspend, whilemaintaining in the inactive state, DRBs associated with the terminal device 150, andperform a RACH procedure for transmission of the uplink data in a connected state.

[00108] In some embodiments, the terminal device 150 may determine whether furtheruplink transmission comprises an uplink signaling. In some embodiments, if determiningthat the further uplink transmission comprises the uplink signaling, the terminal device 150may suspend DRBs associated with the terminal device 150, and perform the further uplinktransmission in a connected state based on a RACH procedure.

[00109] In some embodiments, if determining that the further uplink transmission does notcomprise the uplink signaling, the terminal device 150 may determine whether a furtherDRB with the further uplink transmission is different from each of the one or more DRBsand the further DRB supports the data transmission in the inactive state. In someembodiments, if determining that the further DRB does not support the data transmission inthe inactive state, the terminal device 150 may suspend DRBs associated with the terminaldevice 150, and perform the further uplink transmission in a connected state based on aRACH procedure. In some embodiments, the terminal device 150 may perform, in theconnected state and based on the RACH procedure, transmission of data in the uplink datathat is not transmitted successfully.

[00110] In some embodiments, if determining that the further DRB is different from eachof the one or more DRBs and supports the data transmission in the inactive state, theterminal device 150 may determine whether the further uplink transmission is to beperformed in the inactive state. In some embodiments, if determining that the furtheruplink transmission is to be performed in the inactive state, the terminal device 150 mayperform the further uplink transmission to the first network device in the inactive state. Insome embodiments, the terminal device 120 may perform, in the inactive state,transmission of data in the uplink data that is not transmitted successfully.

[00111] FIG. 5 illustrates an example method 500 of communication implemented at a firstnetwork device (i.e., a current serving network device) in accordance with someembodiments of the present disclosure. For example, the method 500 may be performedat the first network device 110 as shown in FIG. 1. For the purpose of discussion, in thefollowing, the method 500 will be described with reference to FIG. 1. It is to beunderstood that the method 500 may include additional blocks not shown and / or may omitsome blocks as shown, and the scope of the present disclosure is not limited in this regard.

[00112] As shown in FIG. 5, at block 510, the first network device 110 may receive uplinkdata transmitted by a terminal device 150 in an inactive state. At block 520, the firstnetwork device 110 may transmit, to the third network device 130, a request for relocating an anchor for a context of the terminal device, the request comprising a first indication as towhether there is remaining data to be transmitted, the third network device maintaining thecontext of the terminal device 150.

[00113] In some embodiments, the indication comprises at least one of the following: UPTNL information for downlink transmission; or a BSR from the terminal device 150.

[00114] In some embodiments, the first network device 110 may further receive a responseto the request from the third network device 130, the response comprising the context and asecond indication that the anchor is not relocated. In some embodiments, the first networkdevice 110 may transmit data packets associated with the uplink data to the third networkdevice 130 based on the context, and release the context of the terminal device 150. Insome embodiments, the second indication comprises UP TNL information for uplinktransmission.

[00115] In some embodiments, the first network device 110 may further receive, from thethird network device 130, a message comprising a connection release message to betransmitted to the terminal device, UP TNL information for uplink transmission and a partof the context comprising at least RLC configuration of the terminal device 150. In someembodiments, the first network device 110 may transmit the uplink data to the thirdnetwork device based on the UP TNL information and the RLC configuration, and transmitthe connection release message to the terminal device 150.

[00116] FIG. 6 illustrates an example method 600 of communication implemented at asecond network device (i.e., a new serving network device) in accordance with someembodiments of the present disclosure. For example, the method 600 may be performedat the second network device 120 as shown in FIG. 1. For the purpose of discussion, inthe following, the method 600 will be described with reference to FIG. 1. It is to beunderstood that the method 600 may include additional blocks not shown and / or may omitsome blocks as shown, and the scope of the present disclosure is not limited in this regard.

[00117] As shown in FIG. 6, at block 610, the second network device 120 receives, fromthe terminal device 150, a first request for resuming connection upon cell reselection of theterminal device 150 from a first cell of the first network device 110 to a second cell of thesecond network device 120 during data transmission in an inactive state of the terminaldevice 150.

[00118] In some embodiments, the data transmission in the inactive state can be performedin the second cell, and the second network device 120 may also receive, from the terminaldevice 150, uplink data in the data transmission that is not transmitted successfully. Insome embodiments, the second network device 120 may also receive, from the terminaldevice 150, a PDCP status report for a DRB in an AM of the RLC layer.

[00119] At block 620, the second network device 120 transmits, to the fourth networkdevice 140 maintaining the context of the terminal device 150, a second request forrelocating an anchor for a context of the terminal device. In some embodiments, thesecond request may comprise user plane transport network layer (UP TNL) information for the data transmission. In these embodiments, the second network device 120 may receivea response to the request from the fourth network device 140, the response comprising thecontext and information about sequence number and hyper frame number of data packetsassociated with the data transmission. In some embodiments, the second network device120 may also receive the data packets from the fourth network device based on the contextand information.

[00120] In some alternative embodiments, the second network device 120 may receive aresponse to the request from the fourth network device 140, the response comprising thecontext. In some embodiments, the second network device 120 may also receive, from thefourth network device 140, a message comprising information about sequence number andhyper frame number of data packets associated with the data transmission, the messagebeing dedicated for transmission of the information. In some embodiments, the secondnetwork device 120 may also receive the data packets from the fourth network device 140based on the context and the information.

[00121] In some embodiments, the second request does not comprise the UP TNLinformation for the data transmission. In these embodiments, the second network device120 may receive, from the fourth network device 140, a third request for obtaining the UPTNL information for the data transmission, and then transmit, to the fourth network device140, the UP TNL information for the data transmission. In some embodiments, the thirdrequest may comprise at least one of PDU session ID or a list of IDs of one or more DRBs.

[00122] FIG. 7 illustrates an example method 700 of communication implemented at athird network device (i.e., a last serving network device during SDT) in accordance withsome embodiments of the present disclosure. For example, the method 700 may beperformed at the third network device 130 as shown in FIG. 1. For the purpose ofdiscussion, in the following, the method 700 will be described with reference to FIG. 1. Itis to be understood that the method 700 may include additional blocks not shown and / ormay omit some blocks as shown, and the scope of the present disclosure is not limited inthis regard.

[00123] As shown in FIG. 7, at block 710, the third network device 130 receives a requestfor relocating an anchor for a context of the terminal device 150 in an inactive state, therequest comprising a first indication as to whether there is remaining data other than uplinkdata to be transmitted, the third network device 130 maintaining the context of the terminaldevice 150. In some embodiments, the first indication may comprise at least one of thefollowing: UP TNL information for downlink transmission; or a BSR from the terminaldevice.

[00124] At block 720, the third network device 130 determines whether the anchor isrelocated based on the first indication. In some embodiments, if determining that theanchor is not to be relocated, at block 730, the third network device 130 transmits, to thefirst network device 110, at least a part of the context for transmission of the uplink data inthe inactive state.

[00125] In some embodiments, the third network device 130 may transmit, to the firstnetwork device 110, a message comprising a connection release message to be transmittedto the terminal device, UP TNL information for uplink transmission and a part of thecontext comprising at least RLC configuration of the terminal device 150. In somealternative embodiments, the third network device 130 may transmit, to the first networkdevice 110, a response to the request to the first network device 110, the responsecomprising the context and a second indication that the anchor is not relocated.

[00126] FIG. 8 illustrates an example method 800 of communication implemented at afourth network device (i.e., a last serving network device upon cell reselection) inaccordance with some embodiments of the present disclosure. For example, the method800 may be performed at the fourth network device 140 as shown in FIG. 1. For thepurpose of discussion, in the following, the method 800 will be described with reference toFIG. 1. It is to be understood that the method 800 may include additional blocks notshown and / or may omit some blocks as shown, and the scope of the present disclosure isnot limited in this regard.

[00127] As shown in FIG. 8, at block 810, the fourth network device 140 receives from thesecond network device 120, a request for relocating an anchor for a context of the terminaldevice 150. The fourth network device 140 maintains the context of the terminal device150. In some embodiments, the request may comprise UP TNL information for uplink anddownlink transmission (i.e., UP TNL information for data forwarding).

[00128] In some embodiments, the request does not comprise UP TNL information foruplink and downlink transmission (i.e., UP TNL information for data forwarding). Inthese embodiments, the fourth network device 140 may transmit, to the second networkdevice 120, a third request for obtaining the UP TNL information for data forwarding, andreceive the UP TNL information from the second network device 120.

[00129] At block 820, the fourth network device 140 determines whether the anchor is tobe relocated. If determining that the anchor is to be relocated, at block 830, the fourthnetwork device 140 transmits, to the second network device 120, information aboutsequence number and hyper frame number of data packets associated with uplink data to be transmitted. In some embodiments, the fourth network device 140 may transmit theinformation in a response to the request to the second network device 120, the responsecomprising the context. In some embodiments, the fourth network device 140 maytransmit the information in a message dedicated for transmission of the information.

[00130] At block 840, the fourth network device 140 transmits the data packets to thesecond network device 120.

[00131] The implementations of the methods described in FIGs. 4-8 substantiallycorrespond to the processes described in connection with FIGs. 2 and 3, and thus otherdetails are not repeated here. With the methods 400-800 according to embodiments of thepresent disclosure, an enhanced mechanism for SDT is achieved, and lossless transmissionfor SDT is attained.Example ofDevice

[00132] FIG. 9 is a simplified block diagram of a device 900 that is suitable forimplementing embodiments of the present disclosure. The device 900 can be consideredas a further example implementation of the first, second, third, fourth network devices 110,120, 130, 140 or the terminal device 150 as shown in FIG. 1. Accordingly, the device 900can be implemented at or as at least a part of the first, second, third, fourth network devices110, 120, 130, 140 or the terminal device 150.

[00133] As shown, the device 900 includes a processor 910, a memory 920 coupled to theprocessor 910, a suitable transmitter (TX) and receiver (RX) 940 coupled to the processor910, and a communication interface coupled to the TX / RX 940. The memory 910 storesat least a part of a program 930. The TX / RX 940 is for bidirectional communications.The TX / RX 940 has at least one antenna to facilitate communication, though in practice anAccess Node mentioned in this application may have several ones. The communicationinterface may represent any interface that is necessary for communication with othernetwork elements, such as X2 / Xn interface for bidirectional communications betweeneNBs / gNBs, Sl / NG interface for communication between a Mobility Management Entity(MME) / Access and Mobility Management Function (AMF) / SGW / UPF and the eNB / gNB,Un interface for communication between the eNB / gNB and a relay node (RN), or Uuinterface for communication between the eNB / gNB and a terminal device.

[00134] The program 930 is assumed to include program instructions that, when executedby the associated processor 910, enable the device 900 to operate in accordance with theembodiments of the present disclosure, as discussed herein with reference to FIGs. 1 to 8.The embodiments herein may be implemented by computer software executable by theprocessor 910 of the device 900, or by hardware, or by a combination of software andhardware. The processor 910 may be configured to implement various embodiments ofthe present disclosure. Furthermore, a combination of the processor 910 and memory 920may form processing means 950 adapted to implement various embodiments of the presentdisclosure.

[00135] The memory 920 may be of any type suitable to the local technical network andmay be implemented using any suitable data storage technology, such as a non-transitorycomputer readable storage medium, semiconductor based memory devices, magneticmemory devices and systems, optical memory devices and systems, fixed memory andremovable memory, as non-limiting examples. While only one memory 920 is shown inthe device 900, there may be several physically distinct memory modules in the device 900.The processor 910 may be of any type suitable to the local technical network, and mayinclude one or more of general purpose computers, special purpose computers,microprocessors, digital signal processors (DSPs) and processors based on multicoreprocessor architecture, as non-limiting examples. The device 900 may have multipleprocessors, such as an application specific integrated circuit chip that is slaved in time to aclock which synchronizes the main processor.

[00136] Generally, various embodiments of the present disclosure may be implemented inhardware or special purpose circuits, software, logic or any combination thereof. Someaspects may be implemented in hardware, while other aspects may be implemented infirmware or software which may be executed by a controller, microprocessor or othercomputing device. While various aspects of embodiments of the present disclosure areillustrated and described as block diagrams, flowcharts, or using some other pictorialrepresentation, it will be appreciated that the blocks, apparatus, systems, techniques ormethods described herein may be implemented in, as non-limiting examples, hardware,software, firmware, special purpose circuits or logic, general purpose hardware orcontroller or other computing devices, or some combination thereof.

[00137] The present disclosure also provides at least one computer program producttangibly stored on a non-transitory computer readable storage medium. The computerprogram product includes computer-executable instructions, such as those included inprogram modules, being executed in a device on a target real or virtual processor, to carryout the process or method as described above with reference to FIGs. 2 to 8. Generally,program modules include routines, programs, libraries, objects, classes, components, datastructures, or the like that perform particular tasks or implement particular abstract datatypes. The functionality of the program modules may be combined or split betweenprogram modules as desired in various embodiments. Machine-executable instructions forprogram modules may be executed within a local or distributed device. In a distributeddevice, program modules may be located in both local and remote storage media.

[00138] Program code for carrying out methods of the present disclosure may be written inany combination of one or more programming languages. These program codes may beprovided to a processor or controller of a general purpose computer, special purposecomputer, or other programmable data processing apparatus, such that the program codes,when executed by the processor or controller, cause the functions / operations specified inthe flowcharts and / or block diagrams to be implemented. The program code may executeentirely on a machine, partly on the machine, as a stand-alone software package, partly onthe machine and partly on a remote machine or entirely on the remote machine or server.

[00139] The above program code may be embodied on a machine readable medium, whichmay be any tangible medium that may contain, or store a program for use by or inconnection with an instruction execution system, apparatus, or device. The machinereadable medium may be a machine readable signal medium or a machine readable storagemedium. A machine readable medium may include but not limited to an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device,or any suitable combination of the foregoing. More specific examples of the machinereadable storage medium would include an electrical connection having one or more wires,a portable computer diskette, a hard disk, a random access memory (RAM), a read-onlymemory (ROM), an erasable programmable read-only memory (EPROM or Flash memory),an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of the foregoing.

[00140] Further, while operations are depicted in a particular order, this should not beunderstood as requiring that such operations be performed in the particular order shown orin sequential order, or that all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processing may beadvantageous. Eikewise, while several specific implementation details are contained inthe above discussions, these should not be construed as limitations on the scope of thepresent disclosure, but rather as descriptions of features that may be specific to particularembodiments. Certain features that are described in the context of separate embodimentsmay also be implemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment may also be implementedin multiple embodiments separately or in any suitable sub-combination.

[00141] Although the present disclosure has been described in language specific tostructural features and / or methodological acts, it is to be understood that the presentdisclosure defined in the appended claims is not necessarily limited to the specific featuresor acts described above. Rather, the specific features and acts described above aredisclosed as example forms of implementing the claims.

Claims

1. A method of communication, comprising: determining, at a terminal device in an inactive state, whether one or more data radio bearers (DRBs) with uplink data to be transmitted support data transmission in the inactive state;in accordance with a determination that the one or more DRBs support the data transmission in the inactive state, determining, based on a payload size associated with the uplink data and a threshold associated with the one or more DRBs, whether the uplink data is to be transmitted in the inactive state; and in accordance with a determination that the uplink data is to be transmitted in the inactive state, transmitting the uplink data to a first network device in the inactive state.

2. The method of claim 1, wherein determining whether the uplink data is to be transmitted in the inactive state comprises: determining a total payload size of the uplink data; and in accordance with a determination that the total payload size is less than a first threshold size, determining that the uplink data is to be transmitted in the inactive state.

3. The method of claim 1, wherein determining whether the uplink data is to be transmitted in the inactive state comprises: determining a payload size of data in the uplink data corresponding to each of the one or more DRBs; and in accordance with a determination that the payload size is less than the second threshold size, determining that the uplink data is to be transmitted in the inactive state.

4. The method of claim 3, wherein the second threshold size is set in association with each of the DRBs.

5. The method of claim 1, wherein transmitting the uplink data comprises: receiving, from the first network device, a configuration about a bandwidth part (BWP) for the data transmission in the inactive state; and performing, based on the configuration, a random access procedure for transmission of the uplink data.

6. The method of claim 1, further comprising: transmitting, to the first network device, an indication as to whether remaining data other than the uplink data is to be transmitted.

7. The method of claim 1, further comprising: determining whether the data transmission in the inactive state can be performed in a second cell of a second network device upon cell reselection from a first cell of the first network device to the second cell; in accordance with a determination that the data transmission in the inactive state can be performed in the second cell, maintaining in the inactive state; and transmitting the uplink data to the second cell in the inactive state.

8. The method of claim 7, further comprising: performing, while maintaining in the inactive state, at least one of the following: a reset of a media access control (MAC) entity of a MAC layer of the terminal device;a release of a MAC cell group configuration for the MAC entity; a re-establishment of a radio link control (RLC) entity of a RLC layer of the terminal device for data radio bearers associated with the terminal device that are not suspended; or a re-establishment of a packet data convergence protocol (PDCP) entity of a PDCP layer of the terminal device for the data radio bearers associated with the terminal device that are not suspended.

9. The method of claim 8, further comprising: transmitting, to the second cell, a PDCP status report for a DRB in an acknowledge mode (AM) of the RLC layer.

10. The method of claim 7, further comprising: in accordance with a determination that the data transmission in the inactive state cannot be performed in the second cell, suspending, while maintaining in the inactive state, DRBs associated with the terminal device; and performing a random access procedure for transmission of the uplink data in a connected state.

11. The method of claim 1, further comprising: determining whether further uplink transmission comprises an uplink signaling; in accordance with a determination that the further uplink transmission comprises the uplink signaling, suspending DRBs associated with the terminal device; and performing the further uplink transmission in a connected state based on a random access procedure.

12. The method of claim 11, further comprising: in accordance with a determination that the further uplink transmission does not comprise the uplink signaling, determining whether a further DRB with the further uplink transmission is different from each of the one or more DRBs and the further DRB supports the data transmission in the inactive state; in accordance with a determination that the further DRB does not support the data transmission in the inactive state, suspending DRBs associated with the terminal device; and performing the further uplink transmission in a connected state based on a random access procedure.

13. The method of claim 12, further comprising: performing, in the connected state and based on the random access procedure, transmission of data in the uplink data that is not transmitted successfully.

14. The method of claim 12, further comprising: in accordance with a determination that the further DRB is different from each of the one or more DRBs and supports the data transmission in the inactive state, determining whether the further uplink transmission is to be performed in the inactive state; and in accordance with a determination that the further uplink transmission is to be performed in the inactive state, performing the further uplink transmission to the first network device in the inactive state.

15. The method of claim 14, further comprising: performing, in the inactive state, transmission of data in the uplink data that is not transmitted successfully.

16. A method of communication, comprising: receiving, at a first network device, uplink data transmitted by a terminal device in an inactive state; and transmitting, to a third network device, a request for relocating an anchor for a context of the terminal device, the request comprising a first indication as to whether there is remaining data to be transmitted, the third network device maintaining the context of the terminal device.

17. The method of claim 16, wherein the indication comprises at least one of the following: user plane transport network layer (UP TNL) information for downlink transmission; or a buffer status report (BSR) from the terminal device.

18. The method of claim 16, further comprising: receiving a response to the request from the third network device, the response comprising the context and a second indication that the anchor is not relocated; transmitting data packets associated with the uplink data to the third network device based on the context; and releasing the context of the terminal device.

19. The method of claim 18, wherein the second indication comprises user plane transport network layer (UP TNL) information for uplink transmission.

20. The method of claim 16, further comprising: receiving, from the third network device, a message comprising a connection release message to be transmitted to the terminal device, user plane transport network layer (UP TNL) information for uplink transmission and a part of the context comprising at least radio link control (RLC) configuration of the terminal device; transmitting the uplink data to the third network device based on the UP TNL information and the RLC configuration; and transmitting the connection release message to the terminal device.

21. A method of communication, comprising: receiving, at a second network device and from a terminal device, a first request for resuming connection upon cell reselection of the terminal device from a first cell of a first network device to a second cell of the second network device during data transmission in an inactive state of the terminal device; and transmitting, to a fourth network device maintaining the context of the terminal device, a second request for relocating an anchor for a context of the terminal device.

22. The method of claim 21, wherein the second request comprises user plane transport network layer (UP TNL) information for the data transmission.

23. The method of claim 22, wherein the data transmission in the inactive state can be performed in the second cell, and further comprising: receiving, from the terminal device, uplink data in the data transmission that is not transmitted successfully.

24. The method of claim 23, further comprising: receiving a packet data convergence protocol (PDCP) status report for a data radio bearer (DRB) in an acknowledge mode (AM) of the RLC layer.

25. The method of claim 22, further comprising: receiving a response to the request from the fourth network device, the response comprising the context and information about sequence number and hyper frame number of data packets associated with the data transmission; and receiving the data packets from the fourth network device based on the context and information.

26. The method of claim 22, further comprising: receiving a response to the request from the fourth network device, the response comprising the context; receiving, from the fourth network device, a message comprising information about sequence number and hyper frame number of data packets associated with the data transmission, the message being dedicated for transmission of the information; and receiving the data packets from the fourth network device based on the context and the information.

27. The method of claim 21, further comprising: receiving, from the fourth network device, a third request for obtaining user plane transport network layer (UP TNL) information for the data transmission; and transmitting, to the fourth network device, the user plane transport network layer (UP TNL) information for the data transmission.

28. The method of claim 27, wherein the third request comprises at least one of an identity of a protocol data unit (PDU) session or a list of identities of one or more data radio bearers (DRBs).

29. A method of communication, comprising: receiving, at a third network device and from a first network device, a request for relocating an anchor for a context of a terminal device in an inactive state, the request comprising a first indication as to whether there is remaining data other than uplink data to be transmitted, the third network device maintaining the context of the terminal device; determining, based on the first indication, whether the anchor is to be relocated; and in accordance with a determination that the anchor is not to be relocated, transmitting, to the first network device, at least a part of the context for transmission of the uplink data in the inactive state.

30. The method of claim 29, wherein the first indication comprises at least one of the following: user plane transport network layer (UP TNL) information for downlink transmission; or a buffer status report (BSR) from the terminal device.

31. The method of claim 29, wherein the transmitting comprises: transmitting, to the first network device, a message comprising a connection release message to be transmitted to the terminal device, user plane transport network layer (UP TNL) information for uplink transmission and a part of the context comprising at least radio link control (RLC) configuration of the terminal device.

32. The method of claim 29, wherein the transmitting comprises: transmitting a response to the request to the first network device, the response comprising the context and a second indication that the anchor is not relocated.

33. A method of communication, comprising: receiving, at a fourth network device and from a second network device, a second request for relocating an anchor for a context of a terminal device, the fourth network device maintaining the context; in accordance with a determination that the anchor is to be relocated, transmitting, to the second network device, information about sequence number and hyper frame number of data packets associated with uplink data to be transmitted; and transmitting the data packets to the second network device.

34. The method of claim 33, wherein the second request comprises user plane transport network layer (UP TNL) information for uplink and downlink transmission associated with the uplink data.

35. The method of claim 34, wherein transmitting the information comprises: transmitting the information in a response to the second request to the second network device, the response comprising the context.

36. The method of claim 34, wherein transmitting the information comprises: transmitting the information in a message dedicated for transmission of the information.

37. The method of claim 33, further comprising: transmitting, to the second network device, a third request for obtaining user plane transport network layer (UP TNL) information for uplink and downlink transmission associated with the uplink data; and receiving the UP TNL information from the second network device.

38. A terminal device comprising: a processor; and a memory coupled to the processor and storing instructions thereon, the instructions, when executed by the processor, causing the terminal device to perform the method according to any of claims 1 to 15.

39. A network device comprising: a processor; and a memory coupled to the processor and storing instructions thereon, the instructions, when executed by the processor, causing the network device to perform the method according to any of claims 16 to 20.

40. A network device comprising: a processor; and a memory coupled to the processor and storing instructions thereon, the instructions, when executed by the processor, causing the network device to perform the method according to any of claims 21 to 28.

41. A network device comprising: a processor; and a memory coupled to the processor and storing instructions thereon, the instructions, when executed by the processor, causing the network device to perform the method according to any of claims 29 to 32.

42. A network device comprising: a processor; and a memory coupled to the processor and storing instructions thereon, the instructions, when executed by the processor, causing the network device to perform the method according to any of claims 33 to 37.

43. A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 1 to 15.

44. A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 16 to 20.

45. A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 21 to 28.

46. A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 29 to 32.

47. A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of claims 33 to 37.