Attacker Identification During Small Data Transmission

Abstract

According to one aspect, a terminal device is provided for: obtaining information indicating transmission of a data unit to the terminal device over a radio bearer when the terminal device is in an inactive state while a small data transmission (SDT) procedure is ongoing; checking whether the radio bearer is configured for an SDT procedure; and deciding whether to avoid further processing and / or decoding of the data unit based at least on the checking.

Description

[Technical Field]

[0001] Various exemplary embodiments relate to wireless communications. [Background technology]

[0002] Small Data Transmission (SDT) is a procedure that allows a terminal device to transmit data and / or signaling while remaining in an inactive state, i.e., without transitioning to a connected state. SDT is enabled on a per-radio-bearer basis. SDT can be initiated by a terminal device, for example, when pending uplink data across all SDT-enabled radio bearers is less than a configured amount, downlink reference signal received power (DL RSRP) is above a predefined threshold, and valid SDT resources are available. When a given terminal device is performing an SDT procedure, the terminal device is vulnerable to the transmission of "garbage" data on any (data) radio bearer by a malicious attacker network node. Therefore, improvements in the processing and security of SDT-related data are needed. Summary of the Invention

[0003] According to one aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims.

[0004] One or more embodiments are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

[0005] In the following, exemplary embodiments will be explained in more detail with reference to the accompanying drawings. [Brief explanation of the drawings]

[0006] [Figure 1] 1 illustrates an exemplary wireless communication system. [Figure 2] 1 illustrates an exemplary process according to an embodiment. [Figure 3] 1 illustrates an exemplary process according to an embodiment. [Figure 4] 1 illustrates an exemplary process according to an embodiment. [Figure 5] 1 illustrates an exemplary process according to an embodiment. [Figure 6] 1 illustrates an exemplary process according to an embodiment. [Figure 7] 1 illustrates an exemplary process according to an embodiment. [Figure 8] 1 illustrates an exemplary process according to an embodiment. [Figure 9] 10 illustrates an exemplary data transmission that can be received by an inactive terminal device while an SDT procedure is in progress. [Figure 10] 1 shows an apparatus according to an embodiment. [Figure 11] 1 shows an apparatus according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0007] The following embodiments are presented by way of example only. Although this specification may refer to "an," "one," or "some" embodiments and / or examples in several places throughout the text, this does not necessarily mean that each reference is to the same embodiment or example, or that a particular feature applies only to a single embodiment and / or example. Single features of different embodiments and / or examples may be combined to provide other embodiments and / or examples.

[0008] As used herein, "at least one of: " and "at least one of " and similar phrases where a list of two or more elements is joined by "and" or "or" mean at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

[0009] The embodiments and examples described herein can be implemented in any communication system including wireless connections. Various exemplary embodiments are described below using a radio access architecture based on Long Term Evolution Advanced (LTE-Advanced, LTE-A) or New Radio (NR, 5G) as an example of an access architecture to which the embodiments can be applied, but the embodiments are not limited to such architectures. It will be apparent to those skilled in the art that the embodiments can also be applied to other types of communication networks with appropriate means by adjusting parameters and procedures accordingly. Some examples of other suitable system options are Universal Mobile Telecommunications System (UMTS) Radio Access Network (UTRAN or E-UTRAN), Long Term Evolution (LTE, essentially the same as E-UTRA), Wireless Local Area Network (WLAN or WiFi), Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth®, Personal Communications Services (PCS), ZigBee®, Wideband Code Division Multiple Access (WCDMA), systems using Ultra Wideband (UWB) technology, sensor networks, Mobile Ad Hoc Networks (MANET), and Internet Protocol Multimedia Subsystem (IMS), or any combination thereof.

[0010] 1 shows an example of a simplified system architecture showing some elements and functional entities, some or all of which are logical units, the implementation of which may differ from those shown. The connections shown in FIG. 1 are logical connections, and the actual physical connections may differ. It will be apparent to those skilled in the art that a system typically includes functions and structures other than those shown in FIG. 1.

[0011] It should be noted that the embodiment is not limited to the system given as an example, and that those skilled in the art can apply this solution to other communication systems with the required characteristics.

[0012] The example of FIG. 1 shows a portion of an exemplary radio access network.

[0013] 1 shows user devices 100 and 102 configured to wirelessly connect to one or more communication channels in a cell served by an access node (e.g., (e / g)NodeB) 104. The physical link from the user devices to the (e / g)NodeB is referred to as the uplink or reverse link, and the physical link from the (e / g)NodeB to the user devices is referred to as the downlink or forward link. It should be appreciated that the (e / g)NodeB or their functionality may be implemented using any node, host, server, or access point, or other entity suitable for such use.

[0014] A communication system typically includes two or more (e / g)NodeBs, which may be configured to communicate with each other over wired or wireless links designed for this purpose. These links may be used for signaling purposes. The (e / g)NodeBs are computing devices configured to control radio resources of the coupled communication system. The NodeBs may also be referred to as base stations, access points, or any other type of interfacing device, including relay stations, capable of operating in a wireless environment. The (e / g)NodeBs include or are coupled to transceivers. A connection is provided from the transceiver of the (e / g)NodeB to an antenna unit that establishes a bidirectional radio link to a user device. The antenna unit may include multiple antennas or antenna elements. The (e / g)NodeBs are further connected to a core network 110 (CN or Next Generation Core NGC). Depending on the system, the counterpart on the CN side may be a Serving Gateway (S-GW, which routes and forwards user data packets), a Packet Data Network Gateway (P-GW) for providing connectivity of user devices (UEs) to external packet data networks, or a Mobility Management Entity (MME), etc.

[0015] The core network 110 may include a location management function (LMF) and / or some other network node for performing position estimation of the terminal device. The LMF may be configured to receive measurement and assistance information from a next generation radio access network (NF-RAN) and the terminal device 100, 102 via an access and mobility management function (AMF) of the core network 110 over an NL interface between the AMF and the LMF to calculate the position of the terminal device 100, 102.

[0016] A user device (also referred to as UE, user equipment, user terminal, terminal device, etc.) illustrates one type of device to which resources on the air interface are allocated and assigned, and therefore any features described herein with respect to a user device can be implemented using a corresponding device, such as a relay node. An example of such a relay node is a Layer 3 repeater (self-backhauling repeater) towards a base station.

[0017] A user device typically refers to a portable computing device, including wireless mobile communication devices operating with or without a subscriber identity module (SIM), including, but not limited to, mobile stations (mobile phones), smartphones, personal digital assistants (PDAs), handsets, devices using wireless modems (such as alarms or measurement devices), laptop and / or touchscreen computers, tablets, game consoles, notebooks, and multimedia devices. It should be recognized that a user device can also be almost exclusively an uplink device, an example of which is a camera or video camera that loads images or video clips onto a network. A user device can also be a device capable of operating in an Internet of Things (IoT) network, a scenario in which objects are provided with the ability to transfer data over a network without the need for person-to-person or person-to-computer interaction. A user device (or in some embodiments, a Layer 3 relay node) is configured to perform one or more of the functions of user equipment. A user device may also be referred to as a subscriber unit, mobile station, remote terminal, access terminal, user terminal, or user equipment (UE), to name just a few names or devices.

[0018] The various techniques described herein can also be applied to cyber-physical systems (CPS), systems of cooperating computational elements that control physical entities. CPS can enable the implementation and utilization of large numbers of interconnected ICT devices (sensors, actuators, processors, microcontrollers, etc.) embedded in physical objects at different locations. Mobile cyber-physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotic devices and electronic devices carried by humans or animals.

[0019] It should be understood that for clarity, the user device is shown in Figure 1 as including two antennas, and the number of receive and / or transmit antennas may, of course, vary depending on the current implementation.

[0020] Furthermore, although the device is shown as a single entity, different units, processors and / or memory units (not all of which are shown in FIG. 1) may be implemented.

[0021] 5G allows for the use of many more base stations or nodes than LTE (the so-called small cell concept), including multiple-input, multiple-output (MIMO) antennas, i.e., macro sites that operate in conjunction with smaller stations and use a variety of radio technologies depending on service demand, use case, and / or available spectrum. 5G mobile communications will support a wide variety of use cases and related applications, including video streaming, augmented reality, various data sharing methods, and various forms of machine-type applications, including vehicle safety, various sensors, and real-time control. 5G is expected to have multiple air interfaces, i.e., sub-6 GHz, cm-wave, and mm-wave, and will also be able to integrate with existing legacy radio access technologies such as LTE. Integration with LTE, at least initially, can be implemented as a system in which macro coverage is provided by LTE and 5G air interface access comes from small cells via aggregation to LTE. In other words, 5G is planned to support both inter-RAT interoperability (e.g., LTE-5G) and inter-RI interoperability (interoperability between air interfaces such as sub-6 GHz-cmWave, sub-6 GHz-cmWave-mmWave, etc.) One of the concepts being considered for use in 5G networks is network slicing, which allows multiple independent and dedicated virtual sub-networks (network instances) to be created within essentially the same infrastructure to run services with different demands regarding latency, reliability, throughput, and mobility.

[0022] The current architecture in LTE networks is fully distributed in the radio and fully centralized in the core network. Low latency applications and services in 5G require content closer to the radio, leading to local breakouts and multi-access edge computing (MEC). 5G enables analytics and knowledge generation to occur at the source of the data. This approach requires leveraging resources that may not be continuously connected to the network, such as laptops, smartphones, tablets, and sensors. MEC provides a distributed computing environment for application and service hosting. MEC also has the ability to store and process content closer to the cellular subscriber for faster response times. Edge computing encompasses a wide range of technologies, including wireless sensor networks, mobile data acquisition, mobile signature analysis, collaborative distributed peer-to-peer ad-hoc networking and processing (which can also be categorized as local cloud / fog computing and grid / mesh computing), dew computing, mobile edge computing, cloudlets, distributed data storage and retrieval, autonomous self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (massive connectivity and / or latency critical), critical communications (autonomous vehicles, road safety, real-time analytics, time-critical control, healthcare applications), etc.

[0023] The communications system may also communicate with or use services provided by other networks, such as the public switched telephone network or the Internet 112. The communications network may also be able to support the use of cloud services, e.g., at least some of the core network operations may be implemented as cloud services (shown in FIG. 1 as "the cloud" 114). The communications system may also comprise a central control entity or the like that provides facilities for networks of different operators to cooperate, e.g., in spectrum sharing.

[0024] Edge cloud can be brought about in the radio access network (RAN) by utilizing network function virtualization (NFV) and software-defined networking (SDN). Using edge cloud can mean that access node operations are performed, at least in part, in a server, host, or node operatively coupled to a remote radio head or base station that includes a radio portion. It is also possible that node operations will be distributed among multiple servers, nodes, or hosts. Application of the cloud RAN architecture allows RAN real-time functions to be performed on the RAN side (in the distributed unit (DU) 104) and non-real-time functions to be performed in a centralized manner (in the centralized unit (CU) 108).

[0025] It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of LTE or may even not exist. Some other technology advancements that are likely to be used are big data and all-IP, which may change the way networks are built and managed. 5G (or New Radio (NR)) networks are designed to support multiple hierarchies, where MEC servers may be located between the core and base stations or nodeBs (gNBs). It should be recognized that MEC may be applied in 4G networks as well.

[0026] 5G can also utilize satellite communications to enhance or complement 5G service coverage, for example, by providing backhauling. Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (IoT) devices or for passengers in cars, or ensuring service availability for critical communications and future rail, maritime, and aviation communications. Satellite communications can utilize geostationary Earth orbit (GEO) satellite systems, but can also utilize low Earth orbit (LEO) satellite systems, especially megaconstellations (systems with hundreds of (nano)satellites deployed). At least one satellite 106 in a megaconstellation can encompass several satellite-enabled network entities that create ground cells. The ground cells can be created through terrestrial relay nodes 104 or by gNBs located on the ground or within the satellite.

[0027] It is apparent to those skilled in the art that the illustrated system is only an example of a part of a radio access system, and that in practice, the system may include multiple (e / g)NodeBs, a user device may access multiple radio cells, and the system may also include other devices, such as physical layer relay nodes or other network elements. At least one of the (e / g)NodeBs may be a home (e / g)NodeB. In addition, multiple different types of radio cells as well as multiple radio cells may be provided in the geographical area of ​​the radio communication system. The radio cells may be macrocells (or umbrella cells), which are large cells typically having a diameter of up to tens of kilometers, or smaller cells such as micro, femto, or picocells. The (e / g)NodeB in FIG. 1 may provide these cells of any type. A cellular radio system may be implemented as a multi-layer network including several types of cells. Typically, in a multi-layer network, one access node provides one or more cells of one type, and therefore multiple (e / g)NodeBs are needed to provide such a network structure.

[0028] To meet the need to improve the deployment and performance of communication systems, the concept of "Plug and Play" (e / g) NodeB was introduced. Typically, a network that can use "Plug and Play" (e / g) includes a Home NodeB Gateway, or HNB-GW (not shown in Figure 1), in addition to the Home (e / g) (H(e / g)). The HNB Gateway (HNB-GW), which is typically installed within the operator's network, can aggregate traffic from multiple HNBs back to the core network.

[0029] 6G networks are expected to employ flexible decentralized and / or distributed computing systems and architectures, as well as ubiquitous computing, with local spectrum licensing, spectrum sharing, infrastructure sharing, and intelligent automated management supported by mobile edge computing, artificial intelligence, short packet communication, and blockchain technologies. Key features of 6G include intelligent connection management and control capabilities, programmability, integrated sensing and communication, reduced energy footprint, reliable infrastructure, scalability, and affordable pricing. In addition, 6G targets new use cases that incorporate the integration of positioning and sensing capabilities into the system definition to unify user experiences across the physical and digital worlds.

[0030] The terminal devices 100, 102 and the network node 104 may be configured to support small data transmission (SDT) to enable data communication while the terminal devices 100, 102 are operating in an inactive state (e.g., a radio resource control (RRC) inactive state). More specifically, the terminal devices 100, 102 and the network node 104 may be configured to support mobile originated SDT (MO-SDT) or mobile terminated SDT (MT-SDT). MO-SDT enables small data transmission in the uplink direction when the terminal device is operating in an inactive state, while MT-SDT enables small data transmission in both the uplink and downlink directions when the terminal device is operating in an inactive state (although the initial trigger transmission in MT-SDT is in the downlink direction). As noted above, SDT may be enabled on a per-radio bearer basis and / or may be initiated by the terminal device 100, 102, for example, when pending uplink data across all SDT-enabled radio bearers is less than a configured amount, DL RSRP is above a predefined threshold, and valid SDT resources are available to the terminal device 100, 102.

[0031] When a given terminal device 100, 102 initiates MO-SDT or when a network node 104 (e.g., an access point or a distributed unit of a distributed access node) indicates MT-SDT to the terminal device 100, 102, the terminal device 100, 102 becomes vulnerable to downlink garbage data transmission on any radio bearers by a malicious attacker access node (or "man-in-the-middle (MITM)"). These radio bearers may include radio bearers not configured for SDT procedures because the terminal device may be served for SDT data transmission / reception by a terminal device-initiated radio access (RA) procedure via physical random access channel (PRACH) resources dedicated to SDT. The terminal device 100, 102 does not have a means to discard unnecessary packets even if a radio bearer is configured but not used for SDT. As a result, the receiver data buffer of the terminal device 100, 102 may easily become full.

[0032] Due to the way SDT works, terminal devices using SDT are vulnerable to attackers because they identify legitimate networks based on RRC messages (e.g., RRCRelease, RRCResume, or RRCSetup messages) that terminate the SDT procedure. Therefore, only after the SDT procedure is terminated can the terminal device determine that it has transmitted or received data from the attacker's network node. In the worst case scenario (when the attacker's network node expires the SDT timer T319a), the terminal device may not be able to identify the attacker at all and may be served by the attacker for up to four seconds (the maximum setting of the SDT timer T319a). Data transmitted by the attacker's network may reach the terminal device's buffer, for example, at the media access control (MAC) layer, where the terminal device can only identify that it has received data blocks (e.g., MAC service data units) for non-SDT radio bearers (i.e., radio bearers not configured for the SDT procedure).

[0033] The embodiments discussed below seek to overcome or at least mitigate the above-mentioned problems by configuring a terminal device to detect (potentially) malicious transmissions and take one or more actions accordingly (e.g., one or more security actions) to avoid (extended) reception of malicious transmissions.

[0034] 2 illustrates a process according to an embodiment for determining whether it is necessary to avoid prolonged reception (and further processing and / or decoding) of unnecessary data transmissions during the execution of an SDT procedure. The process of FIG. 2 may be performed by an apparatus (e.g., a computing device). Specifically, the apparatus may be a terminal device (e.g., either terminal device 100 or 102 of FIG. 1) or part thereof, or a device communicatively connected to a terminal device. In the following, the entity performing the process will be referred to as a terminal device for simplicity.

[0035] 2, it is initially assumed that the terminal device is operating in an inactive state, which may be an RRC inactive state (or equivalently, an RRC_INACTIVE state).

[0036] It is also assumed that initially, an SDT procedure (e.g., MO-SDT procedure and / or MT-SDT procedure) is ongoing. For example, a terminal device may be performing an SDT procedure in communication with a network node. One or more (data) radio bearers may be configured to be used by the terminal device for the SDT procedure. Also, one or more additional radio bearers may be configured for the terminal device but not used by the terminal device for the SDT procedure. The SDT procedure may include a (small) data transmission from (e.g., in the uplink direction) and / or to (e.g., in the downlink direction) the terminal device. The SDT procedure may use one or more configured grant (CG) resources and / or one or more random access channel (RACH) resources to schedule this transmission.

[0037] The SDT procedure may be initiated by the terminal device, for example, in response to pending uplink data across all SDT-enabled / configured radio bearers being less than a configured amount, downlink RSRP exceeding a predetermined threshold, and valid SDT resources being available. The SDT procedure may be initiated by transmission over RACH resources (which may be configured via system information) or type 1 CG resources (which may be configured by dedicated signaling in the RRCRelease message). SDT resources may be configured on the initial bandwidth part (BWP) for RACH and / or CG. RACH and CG resources for SDT may be configured on either or both normal uplink (NUL) and supplementary uplink (SUL) carriers. CG resources for the SDT procedure may only be valid within the primary cell (PCell) of the terminal device when the RRCRelease message with a suspend indication is received. CG resources may be associated with one or more synchronization signal blocks (SSBs). For RACH, the network can configure two-step and / or four-step RA resources for SDT. If both two-step and four-step RA resources for SDT are configured, the terminal device may be able to select the RA type to be used.

[0038] The terminal device obtains information indicating a data communication (e.g., transmission of a data unit) to the terminal device over a radio bearer when the terminal device is in an inactive state while an SDT procedure is in progress, in block 201. The radio bearer may be a data radio bearer (DRB) or a signaling radio bearer (SRB). The data communication may include, for example, a data block, a data unit, a media access control (MAC) protocol data unit (PDU), a MAC sub-PDU, and / or a MAC service data unit (MAC SDU).

[0039] In some embodiments, the data communication may be a downlink data communication.

[0040] In some embodiments, obtaining the information in block 201 may include (or consist of) receiving the information from a network node. The network node may be, for example, an access node, a distributed unit of a distributed access node, or a relay node. In some cases, the network node may be, in particular, a malicious attacker network node that intentionally transmits "garbage" data.

[0041] In some embodiments, obtaining information in block 201 may include (or consist of) obtaining information from a lower layer.

[0042] In some embodiments, obtaining the information in block 201 may include (or consist of) obtaining a MAC PDU, a MAC sub-PDU (including or consisting of a MAC sub-header and a MAC SDU), or just a MAC sub-header.

[0043] In some embodiments, the information indicating the data communication includes or may be a logical channel identifier (LCID) or extended LCID (eLCID). This LCID or eLCID may be associated with a radio bearer. The LCID (or equivalently, the LCID field or value or index) identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC Control Element (MAC CE) or padding. The LCID has a size of 6 bits. The eLCID is an extended version of the LCID with a size of 1 byte or 2 bytes depending on the associated LCID value.

[0044] In some embodiments, the terminal device may also obtain (or receive from the network node) a data communication (eg, a data block such as a MAC PDU and / or MAC SDU and / or MAC sub-PDU itself) in block 201 .

[0045] In some embodiments, the data communication may include or be a MAC Service Data Unit (MAC SDU). The MAC SDU may be included in a MAC sub-PDU of a transmitted MAC PDU. Additionally or alternatively, the information indicating the data communication may include or be a header of the MAC sub-PDU or a portion of the header of the MAC sub-PDU.

[0046] In block 202, the terminal device checks whether the radio bearer (defined by the acquired information) is configured for an SDT procedure. This check in block 202 can be performed based on the information acquired in block 201. For example, the terminal device can check whether the radio bearer is configured for an SDT procedure based on the LCID provided in the MAC subheader. Alternatively, for example, the terminal device may determine one or more LCIDs associated with the radio bearer configured for the SDT procedure and check whether the acquired LCID value is one of the one or more LCIDs. These examples may also be applied to eLCIDs.

[0047] In block 203, the terminal device determines whether to avoid further processing and / or decoding of the data communication based at least on the confirmation (or the confirmation result). In some embodiments, as described below in connection with FIG. 5, the decision in block 203 may also be based on whether a radio bearer that is not configured for an SDT procedure satisfies at least one of one or more predefined criteria.

[0048] 3 illustrates a process according to an embodiment for avoiding lengthy processing and / or decoding of unnecessary data transmissions during an SDT procedure. The process of FIG. 3 may be performed by an apparatus (e.g., a computing device). Specifically, the apparatus may be a terminal device (e.g., either terminal device 100 or 102 of FIG. 1) or part thereof, or a device communicatively connected to a terminal device. In the following, the entity performing the process will be referred to as the terminal device for simplicity.

[0049] 3, similar to that discussed with respect to FIG. 2, it is initially assumed that the terminal device is operating in an inactive state (e.g., an RRC inactive state) and that an SDT procedure (e.g., an MO-SDT procedure and / or an MT-SDT procedure) is ongoing. For example, the terminal device may be performing an SDT procedure in communication with a network node. One or more radio bearers may be configured to be used by the terminal device for the SDT procedure.

[0050] Similar to block 201 of Figure 2, the terminal device obtains, in block 301, information indicating a data communication (e.g., transmission of a data unit) to the terminal device over a radio bearer (and optionally, the data communication itself) when the terminal device is in an inactive state while an SDT procedure is ongoing, and checks whether the radio bearer is configured for an SDT procedure in block 302. The description provided in relation to blocks 201 and 202 of Figure 2 may also apply mutatis mutandis to blocks 301 and 302 of Figure 3, respectively.

[0051] In response to the radio bearer being configured for the SDT procedure in block 303, the terminal device remains in the inactive state without performing any (security) action (or any of the actions described below, in particular in relation to block 304) in block 305. The SDT procedure may also be continued in this case. After successful completion of the SDT procedure, the terminal device may transition from the inactive state to an idle state or a connected state, or may remain in the inactive state.

[0052] In response to the radio bearer not being configured for the SDT procedure in block 303, the terminal device performs one or more actions to avoid further processing and / or decoding of data communications (or data units) associated with the radio bearer in block 304. Optionally, the one or more actions may also enable avoiding processing and / or decoding of any further data communications (e.g., data units) associated with the radio bearer while the SDT procedure is ongoing. The one or more actions may be security actions. The one or more actions may generally enable avoiding (further) processing and / or decoding of any data associated with the radio bearer (i.e., any data received via the radio bearer) at least while the SDT procedure is ongoing. Thus, in this case, the terminal device effectively assumes that the radio bearer is likely associated with data transmissions by a malicious attacker network node and thus prevents any (further) exposure to such harmful data transmissions.

[0053] In some embodiments in which the terminal device also obtains the data communication (e.g., data units such as MAC PDUs and / or MAC SDUs and / or MAC sub-PDUs) itself in block 301, the one or more actions performed in block 304 include: - storing the data communication (or a part thereof) in a buffer; - storing the data communication (or a part thereof) in a buffer and flushing the data communication stored in the buffer; - Discarding data transmissions, or - suspending the transmission of data communication to higher layers; It may include at least one of:

[0054] In some embodiments, the one or more actions performed in block 304 may include discarding the data communication (e.g., a MAC sub-PDU) and / or indicating to a higher layer (e.g., the RRC layer) that a data communication has been received over a radio bearer that is not configured for an SDT procedure.

[0055] In some embodiments, the one or more actions performed in block 304 may include at least a transition from an inactive state to an idle state (e.g., an RRC idle or RRC_IDLE state). For example, the terminal device may initiate the action upon transitioning to the RRC_IDLE state.

[0056] In some embodiments, the transition to the (RRC) idle state may include or be accompanied by at least one (or all) of the following actions (in addition to the actual step of entering RRC_IDLE): - Reset your MAC, - If the pendingRNA-Update variable is set to true, set it to false, - stop timer T390 for all access categories, if running, and perform the access restriction relaxation steps associated with it; - discard the cell reselection priority information provided by cellReselectionPriorities if stored; - stopping timer T320 if it is running, - stop all running timers except timers T302, T320, T325, T330, T331, and T400, - Destroy the UE Inactive Access Stratum (AS) context if it exists; - Releases suspendConfig if configured, - Delete all entries in VarConditionalReconfig for MCG and SCG, if they exist, - for each measId, if the reportType of the associated reportConfig is set to condTriggerConfig, remove the entry associated with the measId (or reportConfig) from VarMeasConfig, - Destroy the KgNB, S-KgNB, S-KeNB, KRRCenc, KRRCint, KUPint, and KUPenc keys, if they exist; - release all radio resources, including, for example, the release of the Radio Link Control (RLC) entity, the Backhaul Adaptation Protocol (BAP) entity, the MAC configuration and associated Packet Data Convergence Protocol (PDCP) entities and the Service Data Adaptation Protocol (SDAP) for all established radio bearers (except Broadcast Multicast Radio Bearers), the Backhaul (BH) RLC channel, the Uu Relay RLC channel, the PC5 Relay RLC channel, and / or the Sidelink Relay Adaptation Protocol (SRAP) entity; - Indicating the release of the RRC connection to higher layers along with the reason for the release; - notify upper layers about the release of all application layer measurement configurations; - discard any application layer measurement reports that have not yet been submitted to a lower layer for transmission; - discard any segments of a stored segmented RRC message, or - Perform cell selection.

[0057] 4 illustrates a process according to an embodiment for ensuring that data is not transmitted over non-SDT radio bearers while a terminal is operating in an active state and an SDT procedure is in progress. The process of FIG. 4 may be performed by an apparatus (e.g., a computing device). In particular, the apparatus may be a network node, or part of a network node, or a device communicatively connected to a network node. The network node may be an access node or a distributed unit of a distributed access node, such as element 104 of FIG. 1. In the following, the entity performing the process will be referred to as the network node for simplicity.

[0058] Figure 4 shows a simplified process using a single step, which can be performed substantially simultaneously with the process of Figure 2 or Figure 3.

[0059] 4, it can be assumed that initially the terminal device has initiated an SDT procedure with the network node over resources dedicated to SDT (e.g., RACH resources). Alternatively, the SDT procedure may have been indicated to the network node by other means, such as as part of a resumeCause field in an (initial) uplink message from the terminal device to the network node.

[0060] In block 401, the network node suspends all data communications (e.g., all transmissions of data blocks or data units) to the terminal device over any radio bearers not configured for SDT procedures when the terminal device is in an inactive state while an SDT procedure involving the terminal device is in progress. For example, (a technical specification) may require that the network node not perform any data communications (e.g., transmissions of data blocks or data units) to the terminal device over any radio bearers not configured for SDT procedures when the terminal device is in an inactive state while an SDT procedure involving the terminal device is in progress, where the SDT procedure may or may not involve the network node itself. By configuring all valid (or legitimate) network nodes in this manner, the terminal device can safely assume that any data communications received over non-SDT radio bearers during an SDT procedure originate from an attacker network node. Note that in some other embodiments, exceptions to this strict rule of not allowing any data communications over non-SDT radio bearers may be implemented, as described below.

[0061] 5 illustrates another process according to an embodiment for avoiding lengthy processing and / or decoding of unnecessary data transmissions during an SDT procedure. The process of FIG. 5 may be performed by an apparatus (e.g., a computing device). Specifically, the apparatus may be a terminal device (e.g., either terminal device 100 or 102 of FIG. 1) or part thereof, or a device communicatively connected to the terminal device. In the following, the entity performing the process will be referred to as the terminal device for simplicity.

[0062] 2 and 3, it is initially assumed that the terminal device is operating in an inactive state (e.g., an RRC inactive state) and that an SDT procedure (e.g., an MO-SDT procedure and / or an MT-SDT procedure) is ongoing. For example, the terminal device may be performing an SDT procedure in communication with a network node. One or more radio bearers may be configured to be used by the terminal device for the SDT procedure.

[0063] Similar to block 201 of Figure 2, the terminal device obtains, in block 501, information indicating a data communication (e.g., transmission of a data unit) to the terminal device over a radio bearer (and optionally the data communication itself) when the terminal device is in an inactive state while an SDT procedure is in progress, and checks whether the radio bearer is configured for an SDT procedure in block 502. The description provided in relation to blocks 201 and 202 of Figure 2 may also apply mutatis mutandis to blocks 501 and 502 of Figure 3, respectively.

[0064] In response to the radio bearer being configured for the SDT procedure in block 503, the terminal device remains in an inactive state in block 507 without performing any action to avoid further processing and / or decoding of data communications associated with the radio bearer, similar to block 304 of FIG. 3.

[0065] However, in response to the radio bearer not being configured for an SDT procedure in block 503, the terminal device does not proceed directly to performing one or more actions to avoid further processing and / or decoding of data communications associated with the radio bearer, in contrast to the process of FIG. 3. Instead, in this case, the terminal device checks in block 504 whether the radio bearer satisfies at least one of one or more predefined criteria. The one or more predefined criteria may define one or more special cases in which the one or more actions (e.g., transition from an inactive state to an idle state) do not need to be performed even if the radio bearer is not configured for an SDT procedure. The one or more predefined criteria may be retained in at least one memory of the terminal device.

[0066] In some embodiments, the one or more predefined criteria may include at least a criterion requiring that the radio bearer be Signaling Radio Bearer 1 (SRB1). SRB1 is the signaling radio bearer (i.e., the radio bearer carrying at least one signaling message) for RRC messages (optionally including piggybacked Non-Access Stratum (NAS) messages) and NAS messages before Signaling Radio Bearer 2 (SRB2) is established. SRB1 uses the Downlink Control Channel (DCCH) logical channel. SRB1 has a higher priority than SRB2. SRB1 is generally used to transmit signaling messages to a terminal device while an SDT procedure (involving the terminal device) is ongoing. However, it should be emphasized that SRB1 is not (explicitly) configured as such for any SDT procedure.

[0067] In some embodiments, the one or more predefined criteria may include at least a criterion requiring the radio bearer to be configured with integrity protection (i.e., configured to ensure that no transmitted data has been corrupted or tampered with). For example, the PDCP associated with the radio bearer may be configured with integrity protection. The terminal device (or, more specifically, its PDCP entity) may then determine, based on the received data communication, in block 504 whether the data communication has passed an integrity check (i.e., whether the integrity protection check was successful or failed). This alternative has the advantage of allowing the initiation of an SDT procedure without previously configuring any SDT radio bearers.

[0068] In some embodiments where the obtaining in block 501 is assumed to include receiving information from a network node (e.g., an access node or a distributed unit of a distributed access node), the one or more predefined criteria may include a criterion requiring that a network node associated with a radio bearer not configured for an SDT procedure is known by the terminal device to be a valid, non-fraudulent (i.e., authentic) network node (or that its associated network is known to be a valid, non-fraudulent network). In general, the terminal device may determine that a network node is a valid, non-fraudulent (or authentic) network node based, for example, on the fact that the radio bearer used for data communication from a given network node during an SDT procedure is an SRB1 or an integrity-protected radio bearer. Thus, referring to Figure 5, if the terminal device has previously (i.e., during a previous execution of the process of Figure 5) received from the same network node a data bearer that is not configured for an SDT procedure but that satisfies at least one of one or more predefined criteria (i.e., being SRB1 or being integrity protected), it can be assumed that this network node is known by the terminal device to be a valid and non-fraudulent (i.e., authentic) network node (and therefore the above criteria are met). Thus, the criteria defining a radio bearer as an SRB1 or integrity-protected radio bearer need only be met once. Thereafter, data communications over any radio bearer from the trusted network node can be successfully transmitted during the SDT procedure.

[0069] In order to keep track of valid and non-fraudulent network nodes and / or networks, the terminal device may maintain a list of valid and non-fraudulent (or trusted) network nodes and / or networks in at least one memory of the terminal device. In response to determining that a given network node is a valid and non-fraudulent network node, the terminal device may add the network node to the list maintained in the at least one memory.

[0070] It should be emphasized that one or more of the different criteria described above can be checked by the terminal device in block 504. If multiple different criteria are defined in block 504, only one of them needs to be met for the result of the determination in block 504 to be positive.

[0071] In response to the radio bearer not satisfying at least one of the one or more predefined criteria in block 504, the terminal device assumes that data communications associated with the radio bearer may likely originate from a malicious attacker network node. Accordingly, the terminal device performs one or more actions in block 505 to prevent further processing and / or decoding of data communications associated with the radio bearer, as described in connection with block 304 of FIG.

[0072] In response to a radio bearer not configured for an SDT procedure satisfying at least one of one or more predefined criteria in block 504, the terminal device activates the radio bearer for an SDT procedure in block 506. Alternatively, the terminal device may assume that the radio bearer is configured for an SDT procedure and resume the radio bearer (this is not shown in FIG. 5).

[0073] In some embodiments, in block 504, in response to a radio bearer that is not configured for SDT procedures satisfying at least one of one or more predefined criteria, except for a criterion requiring that the network node associated with the radio bearer be known by the terminal device to be a valid, non-rogue network node, the terminal device may determine that the network node is a valid, non-rogue network node. As a result, the terminal device may add the network node to a list of valid, non-rogue network nodes.

[0074] Figure 6 illustrates a process for transmitting data on a radio bearer not configured for SDT procedures, according to an embodiment. The process of Figure 6 may be performed by an apparatus (e.g., a computing device). In particular, the apparatus may be a network node, or part thereof, or a device communicatively connected to a network node. The network node may be an access node or a distributed unit of a distributed access node, such as element 104 of Figure 1. In the following, the entity performing the process will be referred to as the network node for brevity. The process of Figure 6 may be performed prior to the execution of the process of Figure 5 in the terminal device.

[0075] Referring to Figure 6, initially, similar to Figure 4, it can be assumed that the terminal device has initiated an SDT procedure with the network node over SDT dedicated resources (e.g. RACH resources), or that the SDT procedure has been indicated to the network node by other means, such as as part of the resumeCause field in an (initial) uplink message from the terminal device to the network node.

[0076] In block 601, the network node suspends all data communication to the terminal device over radio bearers that are not configured for SDT procedures and that are not SRB1 or configured with integrity protection when the terminal device is in an inactive state while an SDT procedure involving the terminal device is ongoing. In other words, similar functionality to block 401 of Figure 4 is performed in block 601, but here two exceptions are made to the suspension of all data communication over non-SDT radio bearers: SRB1 and integrity protected radio bearers. As explained in relation to Figure 5, the terminal device can be configured to receive data on these types of radio bearers even if these radio bearers are not configured for SDT procedures.

[0077] In some embodiments, block 601 may be omitted.

[0078] Furthermore, the network node transmits a data communication to the terminal device over a radio bearer not configured for the SDT procedure when the terminal device is in an inactive state while an SDT procedure involving the terminal device is ongoing, in block 602. Here, the radio bearer is specifically an SRB1 or a radio bearer configured with integrity protection. The data communication may include or be transmitted along with information indicating the data communication to the terminal device over the radio bearer (e.g., an LCID or eLCID).

[0079] When the network node acquires data to be transmitted over a radio bearer not configured for the ongoing SDT procedure (before the transmission of block 602), there may be one or more other radio bearers not configured with integrity protection that have data waiting to be transmitted to the terminal device. In such a case, the network node may first authenticate itself before transmitting the more recently acquired data on at least one of those (earlier) radio bearers. Thanks to that authentication, during a later transmission, the terminal device knows that the network node is a valid and non-rogue network node, and the transmission can be performed using any SDT or non-SDT radio bearer (as described above). In this way, it is possible to initiate an SDT procedure without previously configuring any SDT radio bearers. If the terminal device receives data not configured with integrity protection before authenticating the network node, the terminal device may identify the access node as an attacker and initiate one or more of the actions described in connection with FIGS. 3 and 5.

[0080] 7 illustrates another process according to an embodiment for avoiding lengthy processing and / or decoding of unnecessary data transmissions during an SDT procedure. The process of FIG. 7 may be performed by an apparatus (e.g., a computing device). Specifically, the apparatus may be a terminal device (e.g., either terminal device 100 or 102 of FIG. 1) or part thereof, or a device communicatively connected to a terminal device. In the following, the entity performing the process will be referred to as the terminal device for simplicity.

[0081] 7, similar to the discussion of any of FIGS. 2-6, it is initially assumed that the terminal device is operating in an inactive state (e.g., an RRC inactive state) and that an SDT procedure (e.g., an MO-SDT procedure and / or an MT-SDT procedure) is ongoing. For example, the terminal device may be performing an SDT procedure in communication with a network node. One or more radio bearers may be configured to be used by the terminal device for the SDT procedure.

[0082] Similar to block 201 of Figure 2, the terminal device, in block 701, obtains information indicating a data communication to the terminal device over a radio bearer when the terminal device is in an inactive state while an SDT procedure is in progress. In block 201, the terminal device may also obtain or receive the data communication itself. In general, the description provided in relation to block 201 of Figure 2 may also apply mutatis mutandis to block 701. Similar to block 202 of Figure 2, the terminal device, in block 702, determines (based on the information) whether the radio bearer is configured for an SDT procedure.

[0083] In response to the radio bearer not being configured for the SDT procedure in block 703, and optionally in response to not satisfying at least one of one or more predefined criteria (not shown in FIG. 7), the terminal device not only performs one or more actions to avoid further processing and / or decoding of the data communication associated with the radio bearer in block 704 (e.g., similar to previous embodiments such as block 304 of FIG. 3), but also logs information regarding the data communication (or the network node from which the information was received) in block 705.

[0084] The logged information may include, for example, information about the network node from which the information was received (e.g., information about the cell and / or tracking provided by the network node) and / or information about the radio bearer from which the data communication was transmitted. - Physical Cell Identifier (PCI), - New Wireless Cell Global Identifier (NCGI), - Tracking Area Identifier (TAI), - SRB1, or - radio bearers, It may include at least one of:

[0085] Here, the PCI, NCGI, and TAI may be the PCI, NCGI, and TAI of the (current) cell of the terminal device (i.e., the cell in which the terminal device was located during acquisition in block 701).

[0086] In some embodiments, the relative order between blocks 704 and 705 may be reversed.

[0087] The terminal device receives a request for reporting logged information regarding data communications over any radio bearers not configured for SDT procedures that were received while an SDT procedure (or any SDT procedure) was in progress, in block 706. The request may request reporting of all or at least some of the logged information. In some embodiments, the request may define what types of logged information should be reported.

[0088] In block 707, the terminal device transmits at least the logged information related to data communication over the radio bearer (i.e., the information logged in block 705), or a portion of the logged information, to the network node.

[0089] In some embodiments, block 706 may be omitted. In such embodiments, the terminal device may be configured to automatically report the logged information (or a portion thereof) according to block 707, e.g., periodically, periodically, upon logging new information, or upon logging a predetermined amount of information since the previous reporting time.

[0090] In some embodiments, the terminal device may log and / or report information only regarding data communications that are associated with radio bearers that are not configured for SDT procedures and that do not satisfy at least one of one or more predefined criteria (discussed in connection with FIG. 5). In other embodiments, at least the logging may be performed for all radio bearers.

[0091] 8 illustrates a process for requesting and receiving information logged by a terminal device according to an embodiment. The process of FIG. 8 may be performed by an apparatus (e.g., a computing device). In particular, the apparatus may be a network node, or part thereof, or a device communicatively connected to a network node. The network node may be an access node or a distributed unit of a distributed access node, such as element 104 of FIG. 1. In the following, the entity performing the process will be referred to as the network node for simplicity.

[0092] The process of Figure 8 may be performed by a network node when a terminal device is performing the process of Figure 7 (or in particular the process of blocks 706-707 of Figure 7). Accordingly, the features and / or definitions described in connection with Figure 7 (in particular those relating to logged information, requesting logged information, and reporting logged information) may also apply here, mutatis mutandis.

[0093] 8, a network node transmits to a terminal device, during an ongoing SDT procedure involving the terminal device, a request for reporting logged information related to data communications received over any radio bearers not configured for the SDT procedure, in block 801. The logged information may be defined as discussed in connection with block 705 of FIG.

[0094] The network node receives logged information from a terminal device, in block 802. The logged information relates to one or more data communications transmitted over one or more radio bearers not configured for SDT procedures. The logged information may include all or at least some of the information logged by the terminal device relating to the one or more data communications received on one or more radio bearers not configured for SDT procedures.

[0095] In some embodiments, block 801 may be omitted. In such embodiments, the terminal device may be configured to automatically report the logged information (or a portion thereof) in accordance with block 707 of FIG. 7, e.g., periodically, periodically, upon logging new information, or upon logging a predetermined amount of information since the previous reporting time.

[0096] 2, 3, 5, and 7 may be performed by, for example, the MAC layer and / or the RRC layer of a terminal device. Note that this is merely an example, and the PHY (i.e., physical) layer, the RLC layer, the PDCP layer, and / or the NAS layer may also be involved. Furthermore, data communications (e.g., data units) described in connection with any of the embodiments may refer to any type of data, including, for example, PHY layer data, MAC layer data, RRC layer data, RLC layer data, PDCP data, or the NAS layer.

[0097] The blocks, related functions, and information exchanges described above with reference to Figures 2-8 are not in absolute chronological order; some of them may be performed simultaneously or in an order different from that presented. Other functions may be performed between or within them, other information may be transmitted, and / or other rules may apply. Also, some of the blocks or portions of the blocks, or one or more pieces of information, may be omitted or replaced with a corresponding block or portion of a block, or one or more pieces of information.

[0098] FIG. 9 illustrates an exemplary data transmission that may be received by a terminal device while operating in an inactive state while an SDT procedure is in progress. The data transmission in FIG. 9 may correspond to a data transmission by a valid, non-rogue network node or an attacker network node. In particular, FIG. 9 illustrates a downlink MAC PDU 900 that includes multiple consecutive MAC sub-PDUs 901, 911, 912, 913, and 914. The MAC PDU 900 may be addressed to the Cell Radio Network Temporary Identifier (C-RNTI) or configured Scheduling Radio Network Temporary Identifier (CS-RNTI) (including the LCID or eLCID) of the MAC entity of the terminal device. The contents of the MAC sub-PDUs 901, 911, 912, and 914 are illustrated in further detail above element 900.

[0099] The MAC sub-PDU 901 is of particular interest in terms of embodiments. The MAC sub-PDU 901 includes a MAC sub-header 902 and a MAC SDU 903. As described in connection with FIGS. 2-8, the MAC sub-header 902 and the MAC SDU 903 may correspond to information indicating a data communication to a terminal device over a radio bearer (which may not be configured for SDT procedures) and the data communication (or data unit) itself, respectively. The MAC sub-header 902 is indicated in FIG. 9 as an "R / F / LCID / L" sub-header, where "R / F / LCID / L" corresponds to fields that may be included in the header ("R," "F," and "L" stand for reserved, format, and length, respectively). The MAC sub-header 902 may include at least an LCID field.

[0100] FIG. 10 provides an apparatus 1001 according to some embodiments. Specifically, FIG. 10 illustrates an apparatus 1001 configured to perform at least some of the terminal device-side functions according to the embodiments described above. The apparatus 1001 may be a terminal device, or a portion thereof (e.g., a computing device), or a device communicatively coupled to a terminal device. The apparatus 1001 may include one or more communication control circuits 1020, such as at least one processor, and at least one memory 1030 including one or more algorithms 1031, such as computer program code (software), where the at least one memory and the computer program code (software), together with the at least one processor, are configured to cause the apparatus to perform any of the example terminal device-side functions described above.

[0101] 10, the communication control circuitry 1020 of the device 1001 may include at least an SDT circuitry 1021 configured to perform at least one SDT procedure (while in an inactive state). The communication control circuitry 1020 of the device 1001 may further include a security action circuitry 1022. The security action circuitry 1022 may be configured to perform, with one or more individual circuits, the functions of the terminal device (or functions associated with the terminal device) described above with any of FIGS. 2, 3, 5, 7, and 9.

[0102] Referring to FIG. 10, memory 1030 may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, etc.

[0103] 10 , the device 1001 may further include different interfaces 1010, such as one or more communication interfaces (TX / RX), including hardware and / or software for achieving communication connectivity over a medium according to one or more communication protocols. The communication interfaces may provide the device 1001 with communication capabilities for communicating in a cellular communication system, for example, enabling communication with one or more terminal devices and / or different network nodes or elements (e.g., different access nodes). The one or more communication interfaces may include standard, well-known components, such as amplifiers, filters, frequency converters, modulators (demodulators), and encoding / decoding circuits, controlled by corresponding control units, as well as one or more antennas. The device 1001 may also include one or more user interfaces.

[0104] FIG. 11 provides an apparatus 1101 (e.g., a computing device) according to some embodiments. Specifically, FIG. 11 illustrates an apparatus 1101 configured to perform at least some of the network node-side functions according to the embodiments described above. The apparatus 1101 may be a network node (e.g., an access node or a distributed unit of a distributed access node), or a portion thereof, or a device communicatively coupled to a network node. The apparatus 1101 may include one or more communication control circuits 1120, such as at least one processor, and at least one memory 1130 including one or more algorithms 1131, such as computer program code (software), where the at least one memory and the computer program code (software), together with the at least one processor, are configured to cause the apparatus to perform any of the example network node-side functions described above.

[0105] 11, the communication control circuit 1120 of the apparatus 1101 includes at least a transmit / receive circuit 1121, which is configured to at least enable data transmission to a terminal device over a radio bearer not configured for an SDT procedure while an SDT procedure is ongoing in the terminal device operating in an inactive state. To this end, the transmit / receive circuit 1121 is configured to perform, using one or more individual circuits, the network node (or network-related) functions described above with reference to FIG. 4 and / or FIG. 6.

[0106] Referring to FIG. 11, memory 1130 may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, etc.

[0107] 11 , the device 1101 may further include different interfaces 1110, such as one or more communication interfaces (TX / RX), including hardware and / or software for achieving communication connectivity over a medium according to one or more communication protocols. The communication interfaces may provide the device 1101 with the communication capability to communicate in a cellular communication system, for example, to enable communication with one or more terminal devices and / or one or more other network nodes or elements. The one or more communication interfaces may include standard, well-known components, such as amplifiers, filters, frequency converters, modulators (demodulators), and encoding / decoding circuits, controlled by corresponding control units, as well as one or more antennas.

[0108] As used herein, the term "circuitry" can refer to one or more or all of the following: (a) a hardware-only circuit implementation, such as an implementation with only analog and / or digital circuitry, and (b) a combination of hardware circuitry and software (and / or firmware), such as (where applicable): (i) a combination of analog and / or digital hardware circuitry and software / firmware, and (ii) any portion of a hardware processor with software, including a digital signal processor, software, and memory, that cooperate to cause an apparatus, such as a terminal device or access node or LMF, to perform various functions, and (c) hardware circuits and processors, such as a microprocessor or portion of a microprocessor, that require software (e.g., firmware) for operation, although software may be absent when not required for operation. This definition of "circuitry" applies to all uses of this term in this application, including any claims. As a further example, as used in this application, the term "circuitry" also encompasses a mere hardware circuit or processor (or processors), or a portion of a hardware circuit or processor, and its associated software and / or firmware implementation. The term "circuitry" also encompasses, for example, baseband integrated circuits for access nodes or terminal devices, or other computing or network devices, where applicable to particular claim elements.

[0109] In one embodiment, at least some of the processes described in connection with Figures 2-8 may be performed by an apparatus (e.g., a computing device for a terminal device, a computing device for a terminal device, a network node, or a network node) comprising corresponding means for performing at least some of the described processes. Some exemplary means for performing a process may include at least one of a detector, a processor (including dual-core and multi-core processors), a digital signal processor, a controller, a receiver, a transmitter, an encoder, a decoder, memory, RAM, ROM, software, firmware, a display, a user interface, a display circuit, a user interface circuit, a user interface software, a display software, a circuit, an antenna, an antenna circuit, and circuitry. In one embodiment, at least one processor, memory, and computer program code form processing means or include one or more computer program code portions for performing one or more operations according to or in accordance with any of the embodiments of Figures 2-8.

[0110] According to one aspect, obtaining information indicating data communication to a terminal device over a radio bearer when the terminal device is in an inactive state while a small data transmission (SDT) procedure is in progress; determining whether a radio bearer is configured for an SDT procedure; determining whether to prevent further processing and / or decryption of the data communication based at least on the confirmation; An apparatus (eg, an apparatus for a terminal device or a terminal device) is provided, comprising means for performing

[0111] According to one aspect, suspending all data communications to the terminal device over any radio bearers not configured for SDT procedures when the terminal device is in an inactive state while an SDT procedure involving the terminal device is in progress; or transmitting a data communication to a terminal device when the terminal device is in an inactive state while an SDT procedure involving the terminal device is in progress over a radio bearer that is not configured for the SDT procedure, the radio bearer being a radio bearer configured with SRB1 or integrity protection; An apparatus (eg, an apparatus for a network node or a network node) is provided that comprises means for performing

[0112] In an embodiment, at least one processor, memory, and computer program code form processing means or include one or more computer program code portions for performing one or more operations according to, or the operations of, any of the embodiments of Figures 2-8.

[0113] The above-described embodiments may also be implemented in the form of a computer program or a computer process defined as a part thereof. The method embodiments described in connection with FIGS. 2 through 8 may be implemented by executing at least a portion of a computer program including corresponding instructions. The computer program may be provided as a computer-readable medium having program instructions stored thereon, or as a non-transitory computer-readable medium having program instructions stored thereon. The computer program may be in source code, object code, or some intermediate form and may be stored in any type of carrier, which may be any entity or device capable of carrying a program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or processor. The computer program medium may be, for example, but not limited to, a recording medium, computer memory, read-only memory, an electrical carrier signal, a communication signal, and a software distribution package. The computer program medium may be a non-transitory medium. Coding software to execute the embodiments shown and described herein is well within the purview of one skilled in the art.

[0114] Although the present invention has been described above with reference to examples shown in the accompanying drawings, it is clear that the present invention is not limited thereto and can be modified in various ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and are intended to illustrate, not limit, the embodiments. As technology advances, it will become apparent to those skilled in the art that the concept of the present invention can be implemented in various ways. Furthermore, it is apparent to those skilled in the art that the described embodiments can be, but do not necessarily have to be, combined with other embodiments in various ways.

Claims

1. A terminal device, at least one processor; and at least one memory that stores instructions that, when executed by the at least one processor, cause the terminal device to perform at least: obtaining information indicating transmission of a data unit to the terminal device over a radio bearer when the terminal device is in an inactive state while a small data transmission (SDT) procedure is in progress; checking whether the radio bearer is configured for the SDT procedure; determining whether to prevent further processing and / or decoding of the data unit based at least on the confirmation; A terminal device that runs

2. The at least one memory and the instructions are transmitted to the terminal device using the at least one processor: in response to determining that the further processing and / or decoding of the data unit is avoided, performing one or more actions to avoid the further processing and / or decoding of the data unit associated with the radio bearer; The terminal device of claim 1 , configured to cause the execution of

3. The one or more actions include at least: The terminal device of claim 2 , further comprising transitioning from the inactive state to an idle state.

4. The at least one memory and the instructions are configured to cause the terminal device, using the at least one processor, to obtain the data unit, and the one or more actions include: storing said data units in a buffer; storing said data units in said buffer and flushing said data units stored in said buffer; - discarding said data unit, or - pausing the transmission of said data units to higher layers; 4. The terminal device according to claim 2, comprising at least one of:

5. The at least one memory and the instructions are transmitted to the terminal device using the at least one processor: in response to determining that the further processing and / or decoding of the data units is not avoided, remaining in the inactive state without performing any action to avoid the further processing and / or decoding of the data units associated with the radio bearer. A terminal device according to any one of claims 1 to 4, configured to cause the execution of

6. The determining step comprises:

6. The terminal device of claim 1, further comprising: determining that the further processing and / or decoding of the data unit is avoided in response to the radio bearer not being configured for the SDT procedure.

7. The determining step comprises:

7. The terminal device of claim 6, comprising determining that the further processing and / or decoding of the data unit is not avoided in response to the radio bearer being configured for the SDT procedure.

8. The determining step comprises:

6. The terminal device of claim 1, further comprising: determining that the further processing and / or decoding of the data unit is avoided in response to the radio bearer not being configured for the SDT procedure and not satisfying any of one or more predefined criteria.

9. The determining step comprises:

9. The terminal device of claim 8, further comprising: determining that the further processing and / or decoding of the data unit is not avoided in response to the radio bearer being configured for the SDT procedure or not being configured for the SDT procedure but satisfying at least one of the one or more predefined criteria.

10. 10. The terminal device according to claim 8 or 9, wherein the one or more predefined criteria include a criterion requiring the radio bearer to be a Signaling Radio Bearer 1 (SRB1).

11. 11. The terminal device according to claim 8, wherein the one or more predefined criteria include a criterion requiring the radio bearer to be a radio bearer configured with integrity protection.

12. 12. The terminal device of claim 8, wherein the obtaining comprises receiving the information from a network node, and wherein the one or more predefined criteria comprises a criterion requiring that the network node associated with the radio bearer is known by the terminal device to be a valid, non-fraudulent network node.

13. The at least one memory and the instructions are transmitted to the terminal device using the at least one processor: determining that the network node is a valid and non-fraudulent network node in response to the radio bearer associated with the network node being SRB1 or the radio bearer associated with the network node being integrity protected; The terminal device of claim 12, configured to cause the execution of

14. Obtaining the information includes: A terminal device according to any preceding claim, comprising receiving said information from a network node.

15. The at least one memory and the instructions may be configured to, using the at least one processor, cause the terminal device to: and configured to cause logging of information relating to the data unit, the logged information comprising: Physical Cell Identifier (PCI), - New Radio Cell Global Identifier (NCGI), - Tracking Area Identifier (TAI), SRB1, or - said radio bearer, The terminal device according to any one of claims 12 to 14, comprising at least one of:

16. The at least one memory and the instructions are transmitted to the terminal device using the at least one processor: receiving from the network node a request for reporting all or at least some of logged information relating to data units received over radio bearers not configured for the SDT procedure while the SDT procedure is in progress; in response to the radio bearer not being configured for the SDT procedure, transmitting at least the logged information related to the data units over the radio bearer, or a portion thereof, to the network node; 16. The terminal device of claim 15, configured to cause the execution of

17. The terminal device according to any one of claims 1 to 16, wherein the data unit comprises at least one of a Medium Access Control (MAC), a Protocol Data Unit (PDU), or a MAC Service Data Unit (MAC SDU).

18. The terminal device according to any one of claims 1 to 17, wherein the information indicating the transmission of the data unit comprises a Logical Channel Identifier (LCID) or an extended LCID (eLCID).

19. The terminal device according to any one of claims 1 to 18, wherein the SDT procedures include at least one of Mobile Originated Small Data Transmission (MO-SDT) or Mobile Terminated Small Data Transmission (MT-SDT).

20. 1. A method comprising: obtaining information indicating transmission of a data unit to a terminal device over a radio bearer when the terminal device is in an inactive state while an SDT procedure is in progress; checking whether the radio bearer is configured for the SDT procedure; determining whether to prevent further processing and / or decoding of the data unit based at least on the confirmation; and A method comprising:

21. A non-transitory computer-readable medium having stored thereon instructions that, when executed by a computing device for a terminal device, cause the computing device to: obtaining information indicating transmission of a data unit to the terminal device over a radio bearer when the terminal device is in an inactive state while an SDT procedure is in progress; checking whether the radio bearer is configured for the SDT procedure; determining whether to prevent further processing and / or decoding of the data unit based at least on the confirmation; and A non-transitory computer-readable medium for causing the execution of

22. a network node, at least one processor; and at least one memory that stores instructions that, when executed by the at least one processor, cause the network node to perform at least: Pausing all transmission of data units to the terminal device over any radio bearer not configured for the SDT procedure when the terminal device is in an inactive state while an SDT procedure involving the terminal device is ongoing, or transmitting, to the terminal device when the terminal device is in the inactive state while the SDT procedure involving the terminal device is ongoing, a data unit over a radio bearer not configured for the SDT procedure, the radio bearer being an SRB1 or a radio bearer configured with integrity protection; A network node that runs

23. 23. The network node of claim 22, wherein the at least one memory and the instructions are configured to cause the network node, using the at least one processor, to perform the suspension.

24. 23. The network node of claim 22, wherein the at least one memory and the instructions are configured to cause the network node, using the at least one processor, to perform the transmitting.

25. The at least one memory and the instructions are used by the at least one processor to cause the network node to: when the terminal device is in the inactive state while the SDT procedure involving the terminal device is ongoing, pausing all transmission of data units to the terminal device over radio bearers that are not configured for the SDT procedure and further that are not the SRB1 or that are not configured with integrity protection; 25. The network node of claim 24, configured to cause the execution of

26. The at least one memory and the instructions are used by the at least one processor to cause the network node to: sending to the terminal device a request to report all or at least some of logged information related to data units received over radio bearers not configured for the SDT procedure while the SDT procedure is ongoing; receiving from the terminal device over the radio bearer at least the logged information related to the data unit; A network node according to any one of claims 22 to 25, configured to cause the execution of

27. The logged information includes: - PCI, - N.C.G.I., - TAI, SRB1, or - said radio bearer, The network node according to any one of claims 22 to 26, comprising at least one of:

28. 1. A method comprising: Pausing all transmission of data units to the terminal device over any radio bearer not configured for the SDT procedure when the terminal device is in an inactive state while an SDT procedure involving the terminal device is ongoing, or transmitting, to the terminal device when the terminal device is in the inactive state while the SDT procedure involving the terminal device is ongoing, a data unit over a radio bearer not configured for the SDT procedure, the radio bearer being an SRB1 or a radio bearer configured with integrity protection; A method comprising:

29. A non-transitory computer-readable medium having stored thereon instructions that, when executed by a computing device for a terminal device, cause the computing device to: Pausing all transmission of data units to the terminal device over any radio bearer not configured for the SDT procedure when the terminal device is in an inactive state while an SDT procedure involving the terminal device is ongoing, or transmitting, to the terminal device when the terminal device is in the inactive state while the SDT procedure involving the terminal device is ongoing, a data unit over a radio bearer not configured for the SDT procedure, the radio bearer being an SRB1 or a radio bearer configured with integrity protection; A non-transitory computer-readable medium for causing the execution of

Images