CN116326142A

CN116326142A - Configuration of small data transmission

Info

Publication number: CN116326142A
Application number: CN202080105522.1A
Authority: CN
Inventors: S·图尔蒂南; B·塞比雷; 吴春丽; J-P·科斯基南
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2020-09-29
Filing date: 2020-09-29
Publication date: 2023-06-23
Also published as: WO2022067542A1; EP4223056A4; EP4223056A1

Abstract

Example embodiments of the present disclosure relate to the configuration of Small Data Transfer (SDT) of stream(s). The first device determines a transmission configuration associated with at least one flow from the first device to the second device. The transmission configuration indicates the permission or non-permission of the small data transmission mode for at least one stream. If data associated with a stream of the at least one stream is to be transmitted, the first device determines whether a small data transmission mode is allowed for the stream based on the transmission configuration, and transmits the data associated with the stream to the second device based on a result of the determination. With this solution, finer control of SDT can be achieved at the flow level, which can improve control of quality of service for individual flows.

Description

Configuration of small data transmission

Technical Field

Embodiments of the present disclosure relate generally to the field of telecommunications and, in particular, relate to methods, apparatuses, devices and computer-readable storage media for configuration of small data transmissions.

Background

In some communication systems, a terminal device may transition between an inactive state and a connected state. In the inactive state, the terminal device may not establish a connection for communication with the network device. In order to avoid unnecessary signaling overhead and power consumption for setting up or reestablishing a connection, support for Small Data Transfer (SDT) for terminal devices in an inactive state has been agreed to without requiring the terminal devices to set up a connection with a network device. However, at present, there is no specific solution for data transmission for terminal devices in an inactive state.

Disclosure of Invention

In general, example embodiments of the present disclosure provide a solution for configuration of small data transmissions. Embodiments that do not fall within the scope of the claims, if any, are to be construed as examples that are useful for understanding the various embodiments of the present disclosure.

In a first aspect, a first device is provided. The first device includes at least one processor; at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to: determining a transmission configuration associated with at least one stream from the first device to the second device, the transmission configuration indicating the allowance or disallowance of the small data transmission mode for the at least one stream; determining whether a small data transmission mode is allowed for the stream based on the transmission configuration according to a determination that data associated with a stream of the at least one stream is to be transmitted; and transmitting data associated with the stream to the second device based on a result of the determination of whether the small data transmission mode is allowed for the stream.

In a second aspect, a second device is provided. The second device includes at least one processor; at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second device to: transmitting configuration information to the first device, the configuration information indicating a transmission configuration associated with at least one stream from the first device to the second device, the transmission configuration indicating an allowance or disallowance of the small data transmission mode for the at least one stream; and receiving data associated with a flow of the at least one flow from the first device, the data associated with the flow being received from the first device based on the transmission configuration.

In a third aspect, a method is provided. The method includes determining, at the first device, a transmission configuration associated with at least one flow from the first device to the second device, the transmission configuration indicating an allowance or disallowance of the small data transmission mode for the at least one flow; determining whether a small data transmission mode is allowed for the stream based on the transmission configuration according to a determination that data associated with a stream of the at least one stream is to be transmitted; and transmitting data associated with the stream to the second device based on a result of the determination of whether the small data transmission mode is allowed for the stream.

In a fourth aspect, a method is provided. The method includes transmitting, at the second device, configuration information to the first device, the configuration information indicating a transmission configuration associated with at least one flow from the first device to the second device, the transmission configuration indicating an allowance or disallowance of the small data transmission mode for the at least one flow; and receiving data associated with a flow of the at least one flow from the first device, the data associated with the flow being received from the first device based on the transmission configuration.

In a fifth aspect, a first apparatus is provided. The first device comprises means for: determining a transmission configuration associated with at least one stream from the first device to the second device, the transmission configuration indicating whether the small data transmission mode is allowed or not allowed for the at least one stream; determining whether a small data transmission mode is allowed for the stream based on the transmission configuration according to a determination that data associated with a stream of the at least one stream is to be transmitted; and transmitting data associated with the stream to the second device based on a result of the determination of whether the small data transmission mode is allowed for the stream.

In a sixth aspect, a second apparatus is provided. The second device comprises means for: transmitting configuration information to the first device, the configuration information indicating a transmission configuration associated with at least one flow from the first device to the second device, the transmission configuration indicating an allowance or disallowance of the small data transmission mode for the at least one flow; and receiving, from the first device, data associated with a flow of the at least one flow, the data associated with the flow being received from the first device based on the transmission configuration.

In a seventh aspect, a computer readable medium is provided. The computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to the third aspect.

In an eighth aspect, a computer readable medium is provided. The computer readable medium comprises program instructions for causing an apparatus to perform at least the method according to the fourth aspect.

It should be understood that the summary is not intended to identify key or essential features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

Some example embodiments will now be described with reference to the accompanying drawings, in which:

FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure may be implemented;

FIG. 2 illustrates an exemplary flow-based architecture for communication between devices;

fig. 3 illustrates signaling flows for configuring SDTs for a flow(s) according to some example embodiments of the present disclosure;

fig. 4 illustrates a flow chart of a method implemented at a terminal device according to some other example embodiments of the present disclosure;

fig. 5 illustrates a flowchart of a method implemented at a network device according to some other example embodiments of the present disclosure;

FIG. 6 illustrates a simplified block diagram of an apparatus suitable for practicing the example embodiments of the present disclosure; and

fig. 7 illustrates a block diagram of an example computer-readable medium, according to some example embodiments of the present disclosure.

The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements.

Detailed Description

Principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described merely for the purpose of illustrating and helping those skilled in the art understand and practice the present disclosure and are not meant to limit the scope of the present disclosure in any way. The embodiments described herein may be implemented in various other ways besides those described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

In this disclosure, references to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be understood that, although the terms "first" and "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "has," "including," "includes" and/or "including" when used herein, specify the presence of stated features, elements, components, and/or groups thereof, but do not preclude the presence or addition of one or more other features, elements, components, and/or groups thereof.

As used in this application, the term "circuitry" may refer to one or more or all of the following:

(a) Pure hardware circuit implementations (such as implementations using only analog and/or digital circuitry), and

(b) A combination of hardware circuitry and software, such as (as applicable):

(i) Combination of analog and/or digital hardware circuit(s) and software/firmware, and

(ii) Any portion of the hardware processor(s), including digital signal processor(s), software, and memory(s) with software that work together to cause a device, such as a mobile phone or server, to perform various functions, and

(c) Hardware circuit(s) and/or processor(s), such as microprocessor(s) or a portion of microprocessor(s), that require software (e.g., firmware)

The operation is performed, but the software may not exist when the operation is not required.

The definition of circuitry is applicable to all uses of that term in this application, including in any claims. As another example, as used in this application, the term circuitry also encompasses hardware-only circuitry or a processor (or multiple processors) or an implementation of a hardware circuit or portion of a processor and its (or their) accompanying software and/or firmware. For example, if applicable to the particular claim elements, the term circuitry also encompasses a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), long Term Evolution (LTE), LTE-advanced (LTE-a), wideband Code Division Multiple Access (WCDMA), high Speed Packet Access (HSPA), narrowband internet of things (NB-IoT), and the like. Furthermore, the communication between the terminal device and the network device in the communication network may be performed according to any suitable generation communication protocol, including, but not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, future fifth generation (5G) communication protocols, and/or any other protocol currently known or to be developed in the future. Embodiments of the present disclosure may be applied to various communication systems. In view of the rapid development of communications, there are, of course, future types of communication techniques and systems that can embody the present disclosure. The scope of the present disclosure should not be limited to only the above-described systems.

As used herein, the term "network device" refers to a node in a communication network through which a terminal device accesses the network and receives services from the network. The network devices may refer to Base Stations (BS) or Access Points (APs), e.g., node BS (NodeB or NB), evolved NodeB (eNodeB or eNB), NR NB (also known as gNB), remote Radio Unit (RRU), radio Header (RH), remote Radio Head (RRH), relay, integrated Access and Backhaul (IAB) nodes, low power nodes (such as femto, pico), non-terrestrial network (NTN) or non-terrestrial network devices (such as satellite network devices, low Earth Orbit (LEO) satellites, and geosynchronous orbit (GEO) satellites), aircraft network devices, etc., depending on the terminology and technology applied.

The term "terminal device" refers to any terminal device capable of wireless communication. By way of example, and not limitation, a terminal device may also be referred to as a communication device, user Equipment (UE), subscriber Station (SS), portable subscriber station, mobile Station (MS), or Access Terminal (AT). The terminal devices may include, but are not limited to, mobile phones, cellular phones, smart phones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal Digital Assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop in-vehicle devices (LMEs), USB dongles, smart devices, wireless customer premise devices (CPE), internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in the context of industrial and/or automated processing chains), consumer electronic devices, devices operating on commercial and/or industrial wireless networks, and the like. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

As used herein, the terms "resource," "transmission resource," "resource block," "Physical Resource Block (PRB)", "uplink resource," or "downlink resource" may refer to any resource used to perform communications (e.g., communications between a terminal device and a network device), such as time domain resources, frequency domain resources, spatial domain resources, code domain resources, or any other resource that enables communications, and the like. Hereinafter, resources in both the frequency domain and the time domain will be used as examples of transmission resources for describing some example embodiments of the present disclosure. Note that example embodiments of the present disclosure are equally applicable to other resources in other domains.

FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure may be implemented. In the communication environment 100, a plurality of communication devices including the first device 110 and the second device 120 can communicate with each other.

In the example of fig. 1, the first device 110 is shown as a terminal device and the second device 120 is shown as a network device serving the terminal device. The service area of the second device 120 may be referred to as the cell 102.

It should be understood that the number of devices shown in fig. 1 and their connections are for illustration purposes only and are not limiting. Environment 100 may include any suitable number of devices suitable for implementing embodiments of the present disclosure. Although not shown, it is to be appreciated that one or more additional devices can be located in cell 102 and that one or more additional cells can be deployed in environment 100. It should be noted that although shown as a network device, the second device 120 may be other devices in addition to the network device. Although shown as a terminal device, the first device 110 may be other devices besides a terminal device.

In some example embodiments, if the first device 110 is a terminal device and the second device 120 is a network device, the link from the second device 120 to the first device 110 is referred to as the Downlink (DL), and the link from the first device 110 to the second device 120 is referred to as the Uplink (UL). In DL, the second device 120 is a Transmitting (TX) device (or transmitter) and the first device 110 is a Receiving (RX) device (or receiver). In the UL, the first device 110 is a TX device (or transmitter) and the second device 120 is an RX device (or receiver).

Communication in communication environment 100 may be implemented in accordance with any suitable communication protocol(s) including, but not limited to, first generation (1G), second generation (2G), third generation (3G), fourth generation (4G), and fifth generation (5G) cellular communication protocols, wireless local network communication protocols such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and/or any other protocol currently known or to be developed in the future. Further, the communication may utilize any suitable wireless communication technology including, but not limited to: code Division Multiple Access (CDMA), frequency Division Multiple Access (FDMA), time Division Multiple Access (TDMA), frequency Division Duplex (FDD), time Division Duplex (TDD), multiple Input Multiple Output (MIMO), orthogonal Frequency Division Multiplexing (OFDM), discrete fourier transform spread OFDM (DFT-s-OFDM), and/or any other technique currently known or developed in the future.

The 3GPP working group introduced a new feature called inactive state. A device (e.g., a terminal device) may transition between an inactive state and a connected state. The INACTIVE state may sometimes be referred to as an INACTIVE mode, an rrc_inactive state, or an INACTIVE state in an rrc_connected mode, and such terms are used interchangeably herein. The CONNECTED state may sometimes be referred to as a CONNECTED mode or rrc_connected state, and such terms are used interchangeably herein.

In the inactive state, the terminal device does not have any dedicated resources (e.g., time and frequency resources) for transmission and/or reception. In the connected state, a connection is established between the terminal device and the network device, and thus the terminal device can perform normal communication with the network device via the connection.

As described above, there is a certain amount of signaling overhead and power consumption to transition the terminal device from the inactive state to the connected state by establishing or reestablishing a connection between the terminal device and the network device. Unnecessary power consumption and signalling overhead may result if connection establishment and subsequent release occurs for each data transmission of the terminal device in an inactive state no matter how small and how frequently the data packets are. Thus, it makes sense to allow transmission data to and/or from a terminal device in an inactive state if the terminal device has intermittent small data packets to transmit. It has been agreed to support Small Data Transfer (SDT) for terminal devices in an inactive state without requiring the terminal device to establish a connection with the network device. As used herein, the term "SDT" refers to a type of transmission in which a small amount of data is triggered, although other terms may also be used.

There are various applications involving the exchange of relatively small amounts of data. For example, in some applications of a mobile device, SDT may include traffic from Instant Messaging (IM) services, heartbeat or keep-alive traffic from IM or email clients and other services, push notifications in various applications, traffic from a wearable device (including, for example, periodic location information), and so forth. In some applications of non-mobile devices, the SDT may include sensor data (e.g., temperature, pressure readings transmitted periodically or in an event-triggered manner in the IoT network), metering and alarm information sent from smart meters, and the like.

Signaling overhead for small data packets from terminal devices in an inactive state is a common problem, not only for network performance and efficiency, but also for UE battery performance. In general, any device in an active state with intermittent small data packets will benefit from enabling SDT. In some example embodiments, SDT may be enabled using messages sent in a Random Access Channel (RACH) procedure and/or using configured grants.

In a communication system, communication between different devices may be supported based on flows (e.g., quality of service (QoS) flows). QoS refers to a technology for smoothly transmitting various types of traffic (mail, data transmission, sound or image) to a user according to its characteristics. The most basic QoS parameters are bandwidth, cell Transmission Delay (CTD), cell Delay Variation (CDV), or Cell Loss Rate (CLR). In some example embodiments, qoS flows may include QoS flows that require guaranteed flow bit rates (referred to as GBR QoS flows) and QoS flows that do not require guaranteed flow bit rates (referred to as non-GBR QoS flows).

Fig. 2 illustrates an exemplary flow-based architecture 200 for communication between devices (e.g., between the first device 110 and the second device 120 in fig. 1). For the first device 110, one or more sessions for communication may be established. In the example architecture 200 of fig. 2, a session 210 between the first device 110 and the second device 120 is shown, although it should be understood that one or more other sessions may also be established. Session 210 may be a Packet Data Unit (PDU) session.

Together with the session 210, at least one Data Radio Bearer (DRB) is established to transmit data packets from the first device 110 to the second device 120. In the example of fig. 2, DRBs 220-1 and 220-2 are shown established for session 210. For ease of discussion, DRB220-1 and DRB 220-2 are collectively or individually referred to as DRB 220. Although two DRBs are explicitly illustrated in fig. 2, in other examples there may be one or more than two DRBs.

In a session, one or more flows are established for data packet transmission. Data packets having different characteristics may be identified as belonging to different streams. Thus, the flow is the finest granularity of QoS differentiation in a session. The flows in the session are identified by an Identification (ID). For example, qoS flows are identified by QoS Flow IDs (QFI). Thus, in a session, different streams may have unique identifications.

To ensure quality of service, such as reliability and delay, data may be mapped to the appropriate flows and DRBs. Thus, there is a two-step mapping from data packets to streams and from streams to DRBs. As shown in the example of fig. 2, streams 230-1, 230-2 are mapped to DRB 220-1 and streams 230-3, 230-4 are mapped to DRB 220-2. For ease of discussion, streams 230-1, 230-2, 230-3, 230-4 are collectively or individually referred to as stream 230. In the case of differentiated flows with QoS, flow 230 may also be referred to as a QoS flow. It will be appreciated that although a particular number of streams are explicitly illustrated in fig. 2, in other examples, a different number of streams may be mapped to a corresponding DRB.

The DRB220 may define data packet processing over the radio interface (Uu). The DRB220 serves packets with the same packet forwarding process. In some example embodiments, flow-to-DRB (flow-to-DRB) mapping by the NG-RAN may be based on the identity of the flow and the associated QoS profile (i.e., qoS parameters and QoS characteristics). In some example embodiments, separate DRBs 220 may be established for flows 230 requiring different packet forwarding processes, or several flows 230 belonging to the same session may be multiplexed in the same DRB 220.

In some example embodiments, the flow-to-DRB mapping may be configured by explicit signaling from the second device 120 to the first device 110, or implicitly via a reflective (reflective) mapping (also referred to as reflective QoS (RQoS)). With the reflection map, the first device 110 can derive a flow-to-DRB map for communications from the first device 110 to the second device 120 based on information available in communications in the reverse direction. For example, for the DRB220, the first device 110 monitors the identity(s) of the flow(s) indicated in the packet received from the second device 120. The first device 110 may then apply the same mapping to the streams from the first device 110 to the second device 120. That is, for the DRB220, the first device 110 maps flows corresponding to the identities and sessions observed in the received packets of the DRB. For example, if a packet of a DRB 220-1 received from a second device 120 indicates an identity of a flow from the second device 120, the flow 230-1 of the first device 110 identified by the same identity may be mapped to the DRB 220-1 according to a reflection map.

In some example embodiments, a default DRB may be configured for session 210. If a flow does not match either the explicit configuration or the reflection map, the flow may be mapped to a default DRB and data associated with the flow may be transmitted via the default DRB.

Since the number of streams to be processed is typically high, it is less likely that the stream-to-DRB mapping rules are explicitly configured in advance. With reflection mapping, the allocation of DRBs between flows can still be controlled by the network, but explicit control signaling for configuration mapping is limited. Control plane delays may also be reduced. Furthermore, by allowing unconfigured flows to be mapped to default DRBs, the network allows the following modes of operation: wherein 1) a default DRB with a radio protocol configured to provide a default QoS is used to carry a large amount of traffic (bulk of traffic); and 2) only streams with specific requirements are dynamically (re-) mapped onto dedicated DRBs when they occur, without involving control signaling. This greatly reduces the amount of signalling required and reduces control plane delay.

Since SDTs may suffer from data loss (e.g., upon cell reselection after SDT transmission), SDTs are not desirable for all communications in a flow-based architecture. Currently, there is no specific solution to configure SDT for a flow-based architecture between devices. The inventors have found that since the number of streams to be processed is typically very high, careful control of the SDT of the streams is required. Therefore, a solution is needed to improve the handling of small data transfers in a stream-based architecture.

According to some example embodiments of the present disclosure, a solution is provided for configuring SDT on a per flow basis. According to the solution, a first device (e.g., a terminal device) may determine a transmission configuration associated with one or more respective flows from the first device to a second device (e.g., a network device). The transport configuration is used to configure the SDT on a per-flow basis to indicate whether SDT mode is allowed or not allowed for one or more respective flows. Depending on the transmission configuration, the first device can determine whether data associated with the stream is allowed to be transmitted to the second device in SDT mode. The second device may control the SDT of the stream transmitted from the first device by sending a transmission configuration to the first device or sending other information to the first device to configure the SDT and the transmission configuration determined by the first device itself. With this solution, finer control of SDT can be achieved at the flow level, which can improve control of QoS for individual flows.

Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

Referring now to fig. 3, fig. 3 illustrates a signaling flow 300 for configuring SDT for a flow(s) according to some example embodiments of the present disclosure. For discussion purposes, the signaling flow 300 will be described with reference to the communication environment 100 in fig. 1 and the flow-based architecture 200 in fig. 2. The signaling flow 300 involves the first device 110 and the second device 120.

In operation, the first device 110 determines 305 a transmission configuration associated with one or more streams 230 from the first device 110 to the second device 120. For example, flow 230 may include a QoS flow. The transport configuration may indicate the allowance or disallowance of the SDT mode for one or more streams 230. Such a transport configuration may also be referred to as a SDT transport configuration or SDT configuration for configuring the SDT on a per flow basis.

In some example embodiments, the transmission configuration of the SDT used by the first device 110 may be partially or fully transmitted from the second device 120. In such an example embodiment, the second device 120 transmits 310 configuration information indicating at least a portion of the transmission configuration to the first device 110, as shown in fig. 3. The configuration information may be transferred when the first device 110 is in a connected state and has a connection established with the second device 120. The second device 120 may control the small data transmission of the first device 110 by providing configuration information. The configuration information may be transmitted from the second device 120 via dedicated signaling (e.g., via Radio Resource Control (RRC) signaling). Configuration information may also be transmitted via other types of signaling, such as broadcast signaling, e.g., through system information block(s) (SIBs).

In some example embodiments, the transmission configuration of the SDT used by the first device 110 may be specified in part or in whole in the first device 110. In this case, the first device 110 may determine how to configure the SDT for one or more streams without increasing signaling from the second device 120.

Through the transport configuration, the first device 110 is able to make decisions regarding SDT at the flow level. In some example embodiments, if the first device 110 is in an inactive state, the transmission configuration may be used to make decisions regarding SDT. In particular, the first device 110 determines whether data associated with any of the streams 230 is to be transmitted, e.g., whether the data is buffered in a data buffer of the stream. If data associated with the stream 230 is found to be transmitted, the first device 110 determines 315 whether SDT mode targeting the stream 230 is allowed based on the transmission configuration. For any flow 230 from the first device 110 to the second device 120, the first device 110 may make a similar decision at the flow level.

For a stream 230 for which SDT mode is allowed, data associated with the stream 230 may be transmitted from the first device 110 in SDT mode, e.g., in case the first device 110 is in an inactive state, or at least the stream 230 may trigger an SDT mode transmission procedure from the first device 110. For a stream 230 for which SDT mode is not allowed, data associated with the stream may be transmitted using conventional connection mode instead of SDT mode. In this case, if the first device 110 is in the inactive state, it can switch to the connected state by restoring the connection with the second device 120, and transmit data via the connection.

In some example embodiments, any suitable layer in the first device, such as Packet Data Convergence Protocol (PDCP), service Data Adaptation Protocol (SDAP), or even higher (e.g., non-access stratum (NAS)) layers, may be used to trigger the SDT or regular connection mode. In some example embodiments, when data associated with a flow arrives at the flow's buffer, the RRC layer may be instructed, e.g., by PDCP or SDAP, whether SDT mode is allowed or not allowed for the flow 230, or whether the RRC layer should trigger an SDT procedure or a connection recovery procedure.

The transport configuration may be defined in various ways to control the SDT of the respective stream(s) from the first device 110 to the second device 120. In some example embodiments, the transmission configuration may indicate one or more IDs or one or more ID ranges (also referred to as identification spaces) of flows that are allowed or not allowed for the SDT mode.

In some example embodiments, the first device 110 may receive configuration information from the second device 120 that includes one or more IDs marked as allowed for SDT mode flows, one or more IDs marked as disallowed for SDT mode flows, one or more ID ranges marked as allowed for SDT mode flows, and/or one or more ID ranges marked as disallowed for SDT mode flows. The second device 120 may control the transmission configuration of the SDT by explicitly indicating the IDs of the flows allowed or not allowed for the SDT mode via the configuration information.

The first device 110 may maintain a list of IDs and/or ranges of IDs for flows that are allowed or not allowed for SDT. If the first device 110 is found to have data to transmit with the flow 230 in an inactive state, the first device 110 may determine whether the ID of the flow 230 matches the maintained ID or ID range in order to determine whether SDT mode is allowed for the flow 230. In some example embodiments, the first device 110 determines that SDT mode is allowed for the stream 230 if the ID of the stream 230 matches the ID of the stream marked as allowed for SDT mode, or if the ID of the stream 230 falls within the range of IDs of streams marked as allowed for SDT mode. In some example embodiments, the first device 110 determines that SDT mode is not allowed for a stream 230 if the ID of the stream 230 does not match any particular ID of the stream marked as allowed or any ID range of the stream, or if the ID of the stream 230 matches or falls within an ID range of a stream marked as not allowed for SDT mode.

In some example embodiments, one or more IDs and/or ID ranges of a flow may identify flows 230 that are mapped to the same DRB 220 or the same session 210. Because of the flexible per-flow configuration, multiple flows 230 mapped to the same DRB 220 or the same session 210 may each be configured to be allowed or disallowed for SDT mode. For example, in fig. 2, flow 230-1 mapped to DRB 220-1 may be configured to be allowed for SDT mode, while flow 230-2 mapped to DRB 220-1 may be configured to be disallowed for SDT mode. In some examples, a difference in configuring SDT modes for the same DRB or the same session at the granularity of the ID range of the flow may also be implemented.

In some example embodiments, if the stream(s) 230 are mapped to the same session 210 or the same DRB220 that are not explicitly configured by the second device 120 to be allowed for SDT mode, they may be considered to be disallowed for SDT mode; vice versa, one or more flows 230 may be explicitly configured to be disallowed for SDT mode, and thus all other flows 230 may be determined to be allowed for SDT mode.

In some cases, the session 210 or DRB220 established between the first device 110 and the second device 120 may be configured to be allowed or disallowed for SDT. In this case, the per-flow configuration proposed in the present disclosure may still allow finer control over SDT. In particular, if session 210 or DRB220 is configured to be allowed for SDT mode, data associated with the disallowed stream(s) may not be transmitted using SDT mode. In this way, even if the first device 110 has only one DRB for a session with the second device 120, the transmission configuration of different streams can be flexibly controlled in terms of small data transmission.

In some example embodiments, the transport configuration may indicate that the SDT mode is allowed or not allowed for new flows mapped to a default DRB established between the first device 110 and the second device 120. The transmission configuration may be indicated by the second device 120 by configuration information or may be specified in the first device 110.

In determining whether the SDT mode is allowed for a flow 230 having associated data to transmit, the first device 110 may determine whether there are stored flow-to-DRB mapping rules for the flow 230, according to a transmission configuration associated with the new flow. The flow-to-DRB mapping rules stored at the first device 110 for a particular flow may indicate that the particular flow was previously mapped to a DRB (e.g., before the first device 100 switched to an inactive state). The mapping of a particular flow to a DRB may be performed according to an explicit configuration, a reflection mapping from the second device 120, or according to a default rule that requires any flow that does not match an explicit configuration and a reflection mapping to a default DRB.

If no flow-to-DRB mapping rules are stored for a flow 230 currently having relevant data to transmit, this flow 230 is indicated as a new flow and the data associated with this new flow may not have been previously transmitted to the second device 120. In this case, the first device 110 may determine that the SDT mode is not allowed for the new flow 230 based on the transmission configuration associated with the new flow. Alternatively, in this case, the first device 110 may determine that SDT mode is allowed for the stream 230 according to the transmission configuration associated with the new stream. In some example embodiments, if no flow-to-DRB mapping rules are stored for the flow 230 currently having relevant data to transmit, the first device 110 may switch to the connected state by restoring the connection with the second device 120 and transmit data associated with the flow 230 via the connection.

In some example embodiments, if the default DRB is configured as an allowed DRB for SDT (referred to as SDT-DRB), then the transport configuration associated with the new flow may be activated for use. In contrast to conventional solutions that allow any new flow mapped to the default SDT-DRB to utilize SDT mode, the transmission configuration presented in this disclosure can control small data transmissions of new flows that do not have an efficient mapping when switching the first device 110 to the inactive state. By preventing new flows from being mapped to SDT-DRBs, flows that are not known to the second device 120 may not be allowed to use SDT mode. In this way, uncertainty in the exposure of a critical data session to data loss that may be introduced by the SDT may be avoided. It should be appreciated that in other example embodiments, the transmission configuration associated with the new flow may be adapted for use regardless of whether the default DRB is configured as an SDT-DRB.

In some example embodiments, the transmission configuration may additionally or alternatively indicate the allowance or disallowance of SDT mode on a per session basis, e.g., on a per PDU session basis. In particular, the transport configuration may indicate whether the SDT is allowed or not allowed for a session 210 (e.g., a PDU session) established between the first device 110 and the second device 120. In an example embodiment, such a transmission configuration may be indicated by the second device 120 through configuration information.

In an example embodiment, if the transport configuration indicates that SDT is allowed for a certain session 210, all streams mapped to that session 210 are allowed to be transported using SDT mode. Thus, for any flow 230 currently having relevant data to transfer, if it is determined that the flow 230 belongs to an allowed session 210, the first device 110 may determine that the SDT mode is allowed for that flow 230.

In an example embodiment, if the transmission configuration indicates that SDT is not allowed for a certain session 210, then all streams mapped to that session 210 are not allowed to be transmitted using SDT mode. In this case, if it is determined that the flow 230 belongs to the non-allowed session 210, the first device 110 may determine that the SDT mode is not allowed for the flow 230.

In some example embodiments, additionally or alternatively, the transmission configuration may indicate allowable restriction criteria for SDT mode in remapping of streams 230 between DRBs 220. The limit criteria may be indicated by the second device 120 through configuration information or may be specified in the first device 110.

The second device 120 may configure the SDT by remapping via the reflection map control flow 230, which may save signaling overhead. For example, using the reflection mapping, the second device 120 can transmit information to the first device 110 indicating that a particular ID of a stream from the second device 120 is mapped to the second DRB 220. If a flow 230 identified by a particular ID indicated from the second device 120 is mapped to a different first DRB 220, the first device 110 may determine that the flow 230 needs to be remapped to the second DRB 220.

After remapping of the flow 230 from the first DRB to the second DRB, the restriction criteria indicated by the transmission configuration may be used to determine whether the SDT mode is still allowed or not allowed for the flow 230 after remapping. In some example embodiments, the restriction criteria may indicate that the SDT mode is allowed or not allowed to be restricted to flows, DRBs, or both flows and DRBs.

Specifically, limiting the permission of the SDT mode to only the flow means that the permission of the SDT mode remains valid at the flow level. In other words, in the case of a remapping of a flow 230 from a first DRB to a second DRB, if SDT mode is allowed for the flow 230 when the flow 230 is mapped to the first DRB, SDT mode is still allowed for the flow 230 after the flow 230 is remapped to the second DRB, regardless of whether the second DRB is configured to be disallowed for SDT. In other examples, if SDT mode is not allowed for stream 230 when stream 230 is mapped to a first DRB, then SDT mode is not allowed after stream 230 is remapped to a second DRB.

Similarly, if the permission of the SDT mode is limited to DRBs, then after remapping, whether the SDT mode is permitted for stream 230 depends on whether the SDT mode is permitted for the second DRB to which stream 230 is remapped. For example, if the SDT mode is allowed for transmission over the second DRB (which means that the second DRB is an SDT-DRB), then the flow 230 may also be allowed to transmit using the SDT mode after remapping to the second DRB. In another example, if the flow 230 is remapped from SDT-DRB to non-SDT-DRB (for which SDT mode is not allowed), then the flow 230 also becomes not allowed for SDT mode. In this case, the remapping may automatically update the allowed flow list of the SDT.

In other examples, if the permission of the SDT mode is limited to both the stream and the DRB, then the SDT mode is permitted for stream 230 after remapping if stream 230 is permitted to use the SDT mode during its mapping to the first DRB and the SDT mode is also permitted for the second DRB. If the stream 230 is not allowed to use the SDT mode or the second DRB is configured to not be allowed to use the SDT mode, then after remapping, the SDT mode is not allowed for the stream either.

In operation, to determine whether SDT mode targeting is allowed for the stream 230 after the stream 230 is remapped to the second DRB, the first device 110 may determine according to the restriction criteria: SDT mode is allowed for the stream 230 when the stream is mapped to the first DRB and/or SDT mode is allowed for transmission over the second DRB.

In some example embodiments, the transmission configuration may additionally or alternatively indicate one or more respective trigger conditions for triggering the SDT mode for one or more flows 230 from the first device 110 to the second device 120. In some examples, the trigger condition may be configured on a per flow basis or on a per DRB basis. The respective trigger conditions may be specific to one flow 230 or to one or more flows mapped to a particular DRB 220. The first device 110 may utilize the flow 230-specific trigger conditions to determine whether SDT mode targeting the flow 230 is allowed. If the trigger condition is met for flow 230, then the SDT mode is determined to be allowed for flow 230.

In some example embodiments, the trigger condition may include a data amount threshold. The data amount threshold may be used to control the corresponding data size of the stream 230 that may be transmitted in SDT mode. In determining whether the SDT mode is allowed for a stream 230 having associated data to transmit, the first device 110 may determine whether the amount of associated data is below a data amount threshold specific to the stream 230. If the amount of data associated with the flow is below the data amount threshold, the first device 110 may determine that SDT mode is allowed for the flow 230. Otherwise, the first device 110 may determine that SDT mode is not allowed for the flow 230.

Alternatively or additionally, the trigger condition may include a channel quality threshold. The channel quality threshold may be measured as a threshold for Reference Signal Received Power (RSRP), a threshold for Reference Signal Received Quality (RSRQ), and/or other factors reflecting channel quality between the first device 110 and the second device 120.

The channel quality threshold may be used to control the corresponding acceptable channel quality for the transmission of stream 230 in SDT mode. In determining whether the SDT mode is allowed for the stream 230 having associated data to transmit, the first device 110 may determine whether a channel quality between the first device 110 and the second device exceeds a channel quality threshold specific to the stream 230. If the channel quality exceeds the channel quality threshold, the first device 110 may determine that the SDT mode is allowed for the stream 230. Otherwise, the first device 110 may determine that SDT mode is not allowed for the stream 230 because the current channel quality is not satisfactory.

In the above example embodiments, the trigger conditions (such as the data amount threshold and the channel quality threshold of the respective flows) may be configured by the second device 120. By configuring the trigger conditions, the second device 120 can control the SDT configured for the flow, thereby protecting a critical data session from exposure to data loss when transmitted using SDT mode.

Some example embodiments related to transmission configurations have been discussed above. The transmission configurations discussed in the different example embodiments may be used in combination. For example, the transmission configuration used by the first device 110 may indicate a respective ID or ID range of allowed or disallowed flows for the SDT mode, and may also indicate that the SDT mode is disallowed for new flows mapped to the default DRB.

Still referring to fig. 3, based on the result of the determination of whether the SDT mode is allowed for the stream 230, the first device 110 transmits 320 data associated with the stream 230 and the second device 120 receives 325 the data transmitted from the first device 110. In particular, if stream 230 having data to be transmitted to second device 120 is allowed to be transmitted in SDT mode, first device 110 may transmit data associated with stream 230 via SDT. For example, the first device 110 may transmit data associated with the stream 230 without transitioning from the inactive state to the connected state. A process associated with small data transfers may be performed between the first device 110 and the second device 120 to complete the transfer of data.

In some cases, the first device 110 may not perform a small data transfer if the stream 230 with data to be transferred to the second device 120 is not allowed to be transferred in SDT mode. Instead, the first device 110 may resume the connection with the second device 120 in order to transmit the data.

Fig. 4 illustrates a flowchart of an example method 400 implemented at a first device, according to some example embodiments of the present disclosure. For discussion purposes, the method 400 will be described from the perspective of the first device 110 with reference to fig. 1 and 2.

At block 410, the first device 110 determines a transmission configuration associated with at least one flow from the first device to the second device. The transmission configuration indicates the permission or non-permission of the small data transmission mode for at least one stream. At block 420, the first device 110 determines whether data associated with a flow of the at least one flow is to be transmitted. If the first device 110 determines that data associated with the stream is to be transmitted, at block 430 the first device 110 determines whether a small data transmission mode is allowed for the stream based on the transmission configuration. If it is determined that data associated with a flow of the at least one flow is to be transmitted, the first device 110 may continue to monitor for data arrival for the at least one flow. At block 440, the first device 110 transmits data associated with the stream to the second device based on the result of the determination of whether the small data transmission mode is allowed for the stream.

In some example embodiments, the transmission configuration is specified in the first device or indicated in configuration information received from the second device.

In some example embodiments, the transmission configuration indicates at least one of: a first identification of a first stream allowed for the small data transfer mode, a second identification of a second stream not allowed for the small data transfer mode, a first identification range of a stream allowed for the small data transfer mode, and a second identification range of a stream not allowed for the small data transfer mode.

In some example embodiments, the first and second flows identified by the first and second identifications are mapped to the same first data radio bearer, and/or wherein the flows identified by the first and second identifications are mapped to the same second data radio bearer.

In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: determining whether the identification of the stream matches at least one of the first identification, the second identification, the first identification range and the second identification range, and determining whether the small data transfer mode is allowed for the stream based on a result of the matching of the identification with the at least one of the first identification, the second identification, the first identification range and the second identification range.

In some example embodiments, the transmission configuration indicates that the small data transmission mode is allowed or not allowed for the new flow mapped to the default data radio bearer. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: the method includes determining whether there is a stored flow-to-data radio bearer mapping rule for a flow, and determining whether a small data transmission mode is allowed or not allowed for the flow based on a transmission configuration according to a determination that there is no stored flow-to-data radio bearer mapping rule for the flow.

In some example embodiments, the transmission configuration indicates whether the small data transmission mode is allowed or not allowed for a session established between the first device and the second device. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: according to a determination that the flow belongs to the session, it is determined whether the small data transfer mode is allowed or not allowed based on the transfer configuration.

In some example embodiments, the transmission configuration indicates a limiting criterion for the permission of a small data transmission mode in remapping of at least one flow between data radio bearers. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: the method further includes receiving, from the second device, information indicating that the flow is to be remapped from the first data radio bearer to the second data radio bearer for transmission, and determining, based on the restriction criteria, whether small data transmission modes are allowed for the flow after the flow is remapped to the second data radio bearer.

In some example embodiments, the restriction standard requires that permission for the small data transfer mode be restricted to at least one of a stream and a data radio bearer. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: determining whether small data transmission mode is allowed for the stream after the stream is remapped to the second data radio bearer by determining at least one of the following in accordance with the restriction criteria: the small data transmission mode is for whether a flow is allowed when mapped to the first data radio bearer and for whether a transmission over the second data radio bearer.

In some example embodiments, the transmission configuration indicates at least one trigger condition for triggering the small data transmission mode for at least one flow, each respective trigger condition of the at least one trigger condition being specific to one of the at least one flow. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: and determining that the small data transmission mode is allowed for the stream according to the determination that the stream-specific trigger condition is met in the at least one trigger condition.

In some example embodiments, the at least one trigger condition includes at least one data amount threshold specific to the at least one flow. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: determining whether an amount of data associated with the flow is below a flow-specific data amount threshold of the at least one data amount threshold, and determining that a small data transfer mode is allowed for the flow based on a determination that the amount of data associated with the flow is below the data amount threshold.

In some example embodiments, the at least one trigger condition includes at least one channel quality threshold specific to the at least one stream. In some example embodiments, determining whether a small data transfer mode is allowed for the stream comprises: determining whether a channel quality between the first device and the second device exceeds a stream-specific channel quality threshold of the at least one channel quality threshold, and determining that a small data transmission mode is allowed for the stream based on a determination that the channel quality exceeds the channel quality threshold.

Fig. 5 illustrates a flowchart of an example method 500 implemented at a second device, according to some example embodiments of the present disclosure. For discussion purposes, the method 500 will be described from the perspective of the second device 120 with reference to fig. 1 and 2.

At block 510, the second device 120 transmits configuration information to the first device 110, the configuration information indicating a transmission configuration associated with at least one flow from the first device to the second device. The transmission configuration indicates the permission or non-permission of the small data transmission mode for at least one stream. At block 520, the second device 120 receives data associated with a flow of the at least one flow from the first device. The data associated with the stream is received from the first device based on the transmission configuration.

In some example embodiments, the transmission configuration indicates at least one of: a first identification of a first flow allowed for the small data transfer mode, a second identification of a second flow not allowed for the small data transfer mode, a first identification range of flows allowed for the small data transfer mode, a second identification range of flows not allowed for the small data transfer mode, the small data transfer mode being allowed or not allowed for a new flow mapped to a default data radio bearer, the small data transfer mode being allowed or not allowed for a session established between the first device and the second device, a restriction criterion of the allowance of the small data transfer mode in remapping, and at least one trigger condition for triggering the small data transfer mode for the at least one flow, each respective trigger condition of the at least one trigger condition being specific to one flow of the at least one flow.

In some example embodiments, the at least one trigger condition includes at least one of: at least one data amount threshold specific to at least one stream, and at least one channel quality threshold specific to at least one stream.

In some example embodiments, a first apparatus (e.g., first device 110) capable of performing any of the methods 400 may include means for performing the respective operations of the methods 400. The component may be implemented in any suitable form. For example, the components may be implemented in circuitry or software modules. The first apparatus may be implemented as the first device 110 or comprised in the first device 110.

In some example embodiments, the first apparatus includes means for: determining a transmission configuration associated with at least one flow from the first apparatus to the second apparatus (e.g., implemented as the second device 120 or included in the second device 120), the transmission configuration indicating an allowance or disallowance of the small data transmission mode for the at least one flow; determining whether a small data transmission mode is allowed for the stream based on the transmission configuration according to a determination that data associated with a stream of the at least one stream is to be transmitted; and transmitting data associated with the stream to the second device based on a result of the determination of whether the small data transmission mode is allowed for the stream.

In some example embodiments, the transmission configuration is specified in the first apparatus or indicated in configuration information received from the second apparatus.

In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: determining whether the identification of the stream matches at least one of the first identification, the second identification, the first identification range and the second identification range, and determining whether the small data transfer mode is allowed for the stream based on a result of the matching of the identification with the at least one of the first identification, the second identification, the first identification range and the second identification range.

In some example embodiments, the transmission configuration indicates that the small data transmission mode is allowed or not allowed for the new flow mapped to the default data radio bearer. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: the method includes determining whether there is a stored flow-to-data radio bearer mapping rule for a flow, and determining whether a small data transmission mode is allowed or not allowed for the flow based on a transmission configuration according to a determination that there is no stored flow-to-data radio bearer mapping rule for the flow.

In some example embodiments, the transmission configuration indicates whether the small data transmission mode is allowed or not allowed for a session established between the first device and the second device. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: according to a determination that the flow belongs to the session, it is determined whether the small data transfer mode is allowed or not allowed based on the transfer configuration.

In some example embodiments, the transmission configuration indicates a limiting criterion for the permission of a small data transmission mode in remapping of at least one flow between data radio bearers. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: the method further includes receiving information from the second device indicating that the flow is to be remapped from the first data radio bearer to the second data radio bearer for transmission, and determining whether small data transmission modes are allowed for the flow after the flow is remapped to the second data radio bearer based on the restriction criteria.

In some example embodiments, the restriction standard requires that permission for the small data transfer mode be restricted to at least one of a stream and a data radio bearer. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: determining whether small data transmission mode is allowed for the stream after the stream is remapped to the second data radio bearer by determining at least one of the following in accordance with the restriction criteria: the small data transmission mode is for whether a flow is allowed when mapped to the first data radio bearer and for whether a transmission over the second data radio bearer.

In some example embodiments, the transmission configuration indicates at least one trigger condition for triggering the small data transmission mode for at least one flow, each respective trigger condition of the at least one trigger condition being specific to one of the at least one flow. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: and determining that the small data transmission mode is allowed for the stream according to the determination that the stream-specific trigger condition is met in the at least one trigger condition.

In some example embodiments, the at least one trigger condition includes at least one data amount threshold specific to the at least one flow. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: determining whether an amount of data associated with the flow is below a flow-specific data amount threshold of the at least one data amount threshold, and determining that a small data transfer mode is allowed for the flow based on a determination that the amount of data associated with the flow is below the data amount threshold.

In some example embodiments, the at least one trigger condition includes at least one channel quality threshold specific to the at least one stream. In some example embodiments, the means for determining whether small data transfer mode targeting flow is allowed comprises means for: determining whether a channel quality between the first device and the second device exceeds a stream-specific channel quality threshold of the at least one channel quality threshold, and determining that a small data transmission mode is allowed for the stream based on a determination that the channel quality exceeds the channel quality threshold.

In some example embodiments, the first apparatus further includes means for performing other operations in some example embodiments of the method 400. In some example embodiments, the component includes at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause operation of the first apparatus.

In some example embodiments, a second apparatus (e.g., second device 120) capable of performing any of the methods 500 may include means for performing the respective operations of the methods 500. The component may be implemented in any suitable form. For example, the components may be implemented in circuitry or software modules. The second apparatus may be implemented as the second device 120 or included in the second device 120.

In some example embodiments, the second apparatus includes means for: transmitting, to a first apparatus (which is implemented as the first device 110 or is included in the first device 110), configuration information indicating a transmission configuration related to at least one flow from the first apparatus to a second apparatus, the transmission configuration indicating an allowance or disallowance of a small data transmission mode for the at least one flow; and receiving, from the first device, data associated with a flow of the at least one flow, the data associated with the flow being received from the first device based on the transmission configuration.

In some example embodiments, the second apparatus further includes means for performing other operations in some example embodiments of the method 500. In some example embodiments, the component includes at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause operation of the second apparatus.

Fig. 6 is a simplified block diagram of a device 600 suitable for implementing example embodiments of the present disclosure. The device 600 may be provided to implement a communication device, for example, the first device 110 or the second device 120 as shown in fig. 1 and 2. As shown, the device 600 includes one or more processors 610, one or more memories 620 coupled to the processors 610, and one or more communication modules 640 coupled to the processors 610.

The communication module 640 is used for two-way communication. The communication module 640 has one or more communication interfaces to facilitate communications with one or more other modules or devices. The communication interface may represent any interface necessary for communication with other network elements. In some example embodiments, the communication module 640 may include at least one antenna.

The processor 610 may be of any type suitable to the local technical network and may include, as non-limiting examples, one or more of the following: general purpose computers, special purpose computers, microprocessors, digital Signal Processors (DSPs), and processors based on a multi-core processor architecture. The device 600 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock that is synchronized to the master processor.

Memory 620 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, read-only memory (ROM) 624, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact Disk (CD), digital Video Disk (DVD), optical disk, laser disk, and other magnetic and/or optical storage. Examples of volatile memory include, but are not limited to, random Access Memory (RAM) 622 and other volatile memory that does not persist during power outages.

The computer program 630 includes computer-executable instructions that are executed by the associated processor 610. Program 630 may be stored in a memory (e.g., ROM 624). Processor 610 may perform any suitable actions and processes by loading program 630 into RAM 622.

Example embodiments of the present disclosure may be implemented by program 630 such that device 600 may perform any of the processes of the present disclosure discussed with reference to fig. 3-5. Example embodiments of the present disclosure may also be implemented in hardware or a combination of software and hardware.

In some example embodiments, program 630 may be tangibly embodied in a computer-readable medium that may be included in device 600 (such as in memory 620) or other storage device that device 600 may access. Device 600 may load program 630 from a computer readable medium into RAM 622 for execution. The computer readable medium may include any type of tangible, non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 7 shows an example of a computer readable medium 700, which may be in the form of a CD, DVD or other optical storage disc. The computer readable medium has stored thereon the program 630.

In general, the various embodiments of the disclosure may be implemented using hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of the disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product comprises computer executable instructions, such as instructions included in a program module, which are executed in a device on a physical or virtual processor to perform any of the methods described above with reference to fig. 3-6. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. Machine-executable instructions of program modules may be executed within local or distributed devices. In a distributed device, program modules may be located in both local and remote memory storage media.

Program code for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable an apparatus, device or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is 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 a computer-readable 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-only memory (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 storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are described in a particular order, this should not be construed as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Also, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

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

Claims

1. A first device, comprising:

at least one processor; and

at least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to:

determining a transmission configuration associated with at least one flow from the first device to a second device, the transmission configuration indicating whether a small data transmission mode is allowed or not allowed for the at least one flow;

in accordance with determining that data associated with a flow of the at least one flow is to be transmitted, determining whether the small data transmission mode is allowed for the flow based on the transmission configuration; and

transmitting the data associated with the flow to the second device based on a result of the determination of whether the small data transmission mode is allowed for the flow.

2. The first device of claim 1, wherein the transmission configuration is specified in the first device or indicated in configuration information received from the second device.

3. The first device of claim 1, wherein the transmission configuration indicates at least one of:

a first identification of a first stream allowed for the small data transfer mode,

a second identification of a second stream not allowed for the small data transfer mode,

a first identification range of allowed streams for the small data transmission mode, and

a second identification range of flows not allowed for the small data transfer mode.

4. A first device according to claim 3, wherein the first and second flows identified by the first and second identifications are mapped to the same first data radio bearer, and/or

Wherein the flows identified by the first and second identification ranges are mapped to the same second data radio bearer.

5. A first device according to claim 3, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to determine whether the small data transfer mode is allowed for the stream by:

Determining whether the identity of the flow matches at least one of the first identity, the second identity, the first identity range, and the second identity range, and

based on a result of a match of the identification with the at least one of the first identification, the second identification, the first identification range, and the second identification range, it is determined whether the small data transfer mode is allowed for the flow.

6. The first device of claim 1, wherein the transmission configuration indicates: the small data transmission mode is allowed or not allowed for new flows mapped to default data radio bearers; and

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to determine whether the small data transfer mode is allowed for the stream by:

determining whether there is a stored flow-to-data radio bearer mapping rule for the flow, and

in accordance with a determination that there is no stored flow-to-data radio bearer mapping rule for the flow, determining whether the small data transmission mode is allowed or not allowed for the flow based on the transmission configuration.

7. The first device of claim 1, wherein the transmission configuration indicates whether the small data transmission mode is allowed or not allowed for a session established between the first device and the second device; and

in accordance with a determination that the flow belongs to the session, a determination is made as to whether the small data transfer mode is allowed or not allowed for the flow based on the transfer configuration.

8. The first device of claim 1, wherein the transmission configuration indicates: a restriction criterion allowing the small data transmission mode in remapping of the at least one stream between data radio bearers; and

receiving information from the second device, the information indicating that the flow is to be remapped from the first data radio bearer to the second data radio bearer for transmission, and

Based on the restriction criteria, it is determined whether the small data transmission mode is allowed for the flow after the flow is remapped to the second data radio bearer.

9. The first device of claim 8, wherein the restriction criteria requires that the permission for the small data transmission mode be restricted to at least one of a flow and a data radio bearer; and

determining whether the small data transmission mode is allowed for the flow after the flow is remapped to the second data radio bearer according to the restriction criteria by determining at least one of:

when the flow is mapped to the first data radio bearer, the small data transmission mode is allowed for the flow, and

the small data transmission mode is for whether transmission over the second data radio bearer is allowed.

10. The first device of claim 1, wherein the transmission configuration indicates at least one trigger condition for triggering the small data transmission mode for the at least one flow, each respective trigger condition of the at least one trigger condition being specific to one flow of the at least one flow; and

in accordance with a determination that a trigger condition specific to the flow of the at least one trigger condition is satisfied, it is determined that the small data transfer mode is allowed for the flow.

11. The first device of claim 10, wherein the at least one trigger condition comprises at least one data amount threshold specific to the at least one flow; and

determining whether the amount of data associated with the flow is below a data amount threshold specific to the flow of the at least one data amount threshold, and

in accordance with a determination that the amount of the data associated with the flow is below the data amount threshold, it is determined that the small data transfer mode is allowed for the flow.

12. The first apparatus of claim 10, wherein the at least one trigger condition comprises at least one channel quality threshold specific to the at least one flow; and

determining whether a channel quality between the first device and the second device exceeds a channel quality threshold specific to the stream of the at least one channel quality threshold, and

in accordance with a determination that the channel quality exceeds the channel quality threshold, it is determined that the small data transmission mode is allowed for the stream.

13. The first device of claim 1, wherein the first device comprises a terminal device and the second device comprises a network device, and

wherein the at least one stream comprises at least one quality of service stream.

14. A second device, comprising:

at least one processor; and

at least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second device to:

Transmitting configuration information to a first device, the configuration information indicating a transmission configuration associated with at least one flow from the first device to the second device, the transmission configuration indicating an allowance or disallowance of a small data transmission mode for the at least one flow; and

data associated with a flow of the at least one flow is received from the first device, the data associated with the flow being received from the first device based on the transmission configuration.

15. The second device of claim 14, wherein the transmission configuration indicates at least one of:

the second identification of the second stream of the small data transfer mode is not allowed,

a first identification range of allowed flows for the small data transfer mode,

a second identification range of flows not allowed for the small data transfer mode,

the small data transfer mode is not allowed for new flows mapped to default data radio bearers,

the small data transfer mode is allowed or not allowed for a session established between the first device and the second device,

Limiting criteria for allowing the small data transfer mode in the remapping, an

At least one trigger condition for triggering the small data transfer mode for the at least one flow, each respective trigger condition of the at least one trigger condition being specific to one of the at least one flow.

16. The second device of claim 15, wherein when the transmission configuration indicates the at least one trigger condition, the at least one trigger condition comprises at least one of:

at least one data amount threshold specific to the at least one flow, and

at least one channel quality threshold specific to the at least one stream.

17. A method, comprising:

determining a transmission configuration associated with at least one stream from a first device to a second device, the transmission configuration indicating whether a small data transmission mode is allowed or not allowed for the at least one stream;

18. The method of claim 17, wherein the transmission configuration is specified in the first device or indicated in configuration information received from the second device.

19. The method of claim 17, wherein the transmission configuration indicates at least one of:

20. The method of claim 17, wherein the transmission configuration indicates: the small data transmission mode is allowed or not allowed for new flows mapped to default data radio bearers; and

wherein determining whether the small data transfer mode is allowed for the stream comprises:

21. The method of claim 17, wherein the transmission configuration indicates: the small data transfer mode is allowed or disallowed for a session established between the first device and the second device; and

22. The method of claim 17, wherein the transmission configuration indicates a restriction criterion that allows the small data transmission mode in remapping of the at least one flow between data radio bearers; and

23. The method of claim 22, wherein the restriction criteria requires that the permission for the small data transmission mode be restricted to at least one of a flow and a data radio bearer; and

24. The method of claim 17, wherein the transmission configuration indicates at least one trigger condition for triggering the small data transmission mode for the at least one flow, each respective trigger condition of the at least one trigger condition being specific to one flow of the at least one flow; and

25. The method of claim 24, wherein the at least one trigger condition comprises at least one data amount threshold specific to the at least one flow; and

26. The method of claim 24, wherein the at least one trigger condition comprises at least one channel quality threshold specific to the at least one stream; and

27. A method, comprising:

transmitting configuration information to a first device, the configuration information indicating a transmission configuration associated with at least one flow from the first device to a second device, the transmission configuration indicating an allowance or disallowance of a small data transmission mode for the at least one flow; and

28. A first apparatus comprising means for:

29. A second apparatus comprising means for:

30. A computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any one of claims 17 to 26 or the method of claim 27.