Method and apparatus for user plane based communication

Abstract

Various embodiments of the present disclosure provide a method for user plane (UP) based communication. The method which may be performed by a first terminal device comprises: performing UP based communication for data of the first terminal device via a common tunnel for a device group or a common session for the device group. The UP based communication is between the first terminal device and a second network node via at least a first network node, and the first terminal device belongs to the device group. In accordance with an exemplary embodiment, the method may optionally further comprise: generating the data of the first terminal device.

Description

METHOD AND APPARATUS FOR USER PLANE BASED COMMUNICATIONFIELD OF THE INVENTION

[0001] The present disclosure generally relates to communication networks, and more specifically, to a method and apparatus for user plane (UP) based communication.BACKGROUND

[0002] This section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0003] Wireless Internet of things (IoT) devices are often battery powered and both the need to change battery and the battery lifetime may be concerns for many potential applications such as asset tracking or environmental / industrial sensors. For this reason, the wireless communications industry has been interested in so-called zero-energy (ZE) devices. ZE devices may refer to wireless IoT devices that do not require battery replacement, and often harvest energy from the environment. In some use cases, such as monitoring the temperature of foodstuffs, the ZE devices may have small batteries that are disposable (e.g., organic, compostable batteries, etc. ) , rechargeable or have very limited capacity.

[0004] The ZE-IoT devices can in addition be of very small form factor and could even be printable and they target ultra-low power consumption to enable operation based on either energy-harvesting from an ambient sources or back-scattering communication (e.g., radio frequency identification (RFID) , etc. ) . That is, instead of relying on energy for communication being provided by a battery it is instead harvested from an ambient source, such as vibrations, solar power, radio frequency (RF) , etc. (in the harvesting case) , or a charge carrier wave (CW) is provided to the device which is modulated and reflected back to a reader (in the back-scattering communication case) . This enables energy autonomous operation during the lifetime of the devices without need for either manual replacement or charging of the batteries. Compared to existing radio access technologies, this may put new requirements on the radio interface and the protocols.SUMMARY

[0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] An ambient IoT (A-IoT) device may connect to a network in various network (NW) topologies. For example, the A-IoT device may communicate with a radio access network (RAN) node directly or via an intermediate user equipment (UE) , and transmit data (e.g., a device identifier (ID) , sensor data, and / or device status, etc. ) towards a core network (CN) . Such data may be transmitted to the network via a UP based connection. However, according to the existing solutions, it may be difficult for an A-IoT device to establish and maintain a UP based connection between the A-IoT device and the CN, e.g., due to insufficient capabilities of the A-IoT device with low-complexity and low-cost implementation.

[0007] Various exemplary embodiments of the present disclosure propose a solution for UP based communication, which may enable a device (e.g., an ultra-low power device, a ZE-IoT device, an A-IoT device, etc. ) to transmit / receive UP data to / from a CN via a RAN node on a common tunnel or session without setting up a dedicated tunnel or session for the device.

[0008] It can be appreciated that the terms “common tunnel” and “common connection” may be used interchangeably in this document. Tunnel may refer to one technology to carry data / packets associated with a first pair of identifiers / addresses over another connection / network associated with a second pair of identifiers / addresses. The packets or data frames may carry two headers including an outer header (associated with the second pair of identifiers / addresses) and an inner header (associated with the first pair of identifiers / addresses) . In an embodiment, the general packet radio service tunneling protocol (GTP) refers to a group of Internet protocol (IP) based communications protocols used to carry general packet radio service (GPRS) within global system for mobile communications (GSM) , universal mobile telecommunications system (UMTS) , long term evolution (LTE) and / or the fifth generation (5G) new radio (NR) radio networks.

[0009] According to a first aspect of the present disclosure, there is provided a method performed by a first terminal device. The method comprises: performing UP based communication for data of the first terminal device via a common tunnel for a device group or a common session for the device group. The UP based communication is between the first terminal device and a second network node via at least a first network node. The first terminal device belongs to the device group. In accordance with an exemplary embodiment, the method may optionally further comprise: generating the data of the first terminal device. The data of the first terminal device may include uplink (UL) data of the first terminal device to be transmitted to the first network node in a predefined format.

[0010] According to a second aspect of the present disclosure, there is provided an apparatus which may be implemented as a first terminal device. The apparatus may comprise one or more processors and one or more memories storing computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the first aspect of the present disclosure.

[0011] According to a third aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the first aspect of the present disclosure.

[0012] According to a fourth aspect of the present disclosure, there is provided an apparatus which may be implemented as a first terminal device. The apparatus may comprise a performing unit and optionally a generating unit. In accordance with some exemplary embodiments, the performing unit may be operable to carry out at least the performing step of the method according to the first aspect of the present disclosure. The generating unit may be operable to carry out at least the generating step of the method according to the first aspect of the present disclosure.

[0013] According to a fifth aspect of the present disclosure, there is provided a method performed by a second terminal device. The method comprises: establishing a common session (e.g., a common protocol data unit (PDU) session, etc. ) between the second terminal device and a second network node. The common session can be shared by different devices in a device group for UP based communication between the different devices and the second network node via a first network node. The device group may be represented by the second terminal device. In accordance with an exemplary embodiment, the method may optionally further comprise: performing UP based communication for data of the second terminal device via the common session. The UP based communication for the data of the second terminal device may be between the second terminal device and the second network node via the first network node.

[0014] According to a sixth aspect of the present disclosure, there is provided an apparatus which may be implemented as a second terminal device. The apparatus may comprise one or more processors and one or more memories storing computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the fifth aspect of the present disclosure.

[0015] According to a seventh aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the fifth aspect of the present disclosure.

[0016] According to an eighth aspect of the present disclosure, there is provided an apparatus which may be implemented as a second terminal device. The apparatus may comprise an establishing unit and optionally a performing unit. In accordance with some exemplary embodiments, the establishing unit may be operable to carry out at least the establishing step of the method according to the fifth aspect of the present disclosure. The performing unit may be operable to carry out at least the performing step of the method according to the fifth aspect of the present disclosure.

[0017] According to a ninth aspect of the present disclosure, there is provided a method performed by a third terminal device. The method comprises: establishing a common session (e.g., a common PDU session, etc. ) between the third terminal device and a second network node. The common session can be shared by different devices in a device group for UP based communication between the different devices and the second network node via the third terminal device and a first network node. The third terminal device is an intermediate device between the device group and the first network node. In accordance with an exemplary embodiment, the method may optionally further comprise: performing UP based communication for data of a first terminal device via the common session. The UP based communication for the data of the first terminal device may be between the first terminal device and the second network node via the third terminal device and the first network node.

[0018] According to a tenth aspect of the present disclosure, there is provided an apparatus which may be implemented as a third terminal device. The apparatus may comprise one or more processors and one or more memories storing computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the ninth aspect of the present disclosure.

[0019] According to an eleventh aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the ninth aspect of the present disclosure.

[0020] According to a twelfth aspect of the present disclosure, there is provided an apparatus which may be implemented as a third terminal device. The apparatus may comprise an establishing unit and optionally a performing unit. In accordance with some exemplary embodiments, the establishing unit may be operable to carry out at least the establishing step of the method according to the ninth aspect of the present disclosure. The performing unit may be operable to carry out at least the performing step of the method according to the ninth aspect of the present disclosure.

[0021] According to a thirteenth aspect of the present disclosure, there is provided a method performed by a first network node. The method comprises: performing UP based communication for data of a first terminal device via a common tunnel for a device group or a common session for the device group. The UP based communication is between the first terminal device and a second network node via at least the first network node. The first terminal device belongs to the device group. In accordance with an exemplary embodiment, the method may optionally further comprise: establishing the common tunnel between the first network node and the second network node.

[0022] According to a fourteenth aspect of the present disclosure, there is provided an apparatus which may be implemented as a first network node. The apparatus may comprise one or more processors and one or more memories storing computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the thirteenth aspect of the present disclosure.

[0023] According to a fifteenth aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the thirteenth aspect of the present disclosure.

[0024] According to a sixteenth aspect of the present disclosure, there is provided an apparatus which may be implemented as a first network node. The apparatus may comprise a performing unit and optionally an establishing unit. In accordance with some exemplary embodiments, the performing unit may be operable to carry out at least the performing step of the method according to the thirteenth aspect of the present disclosure. The establishing unit may be operable to carry out at least the establishing step of the method according to the thirteenth aspect of the present disclosure.

[0025] According to a seventeenth aspect of the present disclosure, there is provided a method performed by a second network node (e.g., a CN node, etc. ) . The method comprises: performing UP based communication for data of a first terminal device via a common tunnel (e.g., a stream control transmission protocol (SCTP) connection or a tunneling protocol user plane (GTP-U) connection, etc. ) for a device group or a common session (e.g., a common PDU session, etc. ) for the device group. The UP based communication is between the first terminal device and the second network node via at least a first network node (e.g., a RAN node, etc. ) . The first terminal device belongs to the device group. In accordance with an exemplary embodiment, the method may optionally further comprise: transmitting, towards one or more devices in the device group via at least the first network node, a message for triggering establishment of the common tunnel and / or the common session.

[0026] According to an eighteenth aspect of the present disclosure, there is provided an apparatus which may be implemented as a second network node. The apparatus may comprise one or more processors and one or more memories storing computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the apparatus at least to perform any step of the method according to the seventeenth aspect of the present disclosure.

[0027] According to a nineteenth aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the seventeenth aspect of the present disclosure.

[0028] According to a twentieth aspect of the present disclosure, there is provided an apparatus which may be implemented as a second network node. The apparatus may comprise a performing unit and optionally a transmitting unit. In accordance with some exemplary embodiments, the performing unit may be operable to carry out at least the performing step of the method according to the seventeenth aspect of the present disclosure. The transmitting unit may be operable to carry out at least the transmitting step of the method according to the seventeenth aspect of the present disclosure.

[0029] According to various exemplary embodiments, a first terminal device (e.g., A-IoT devices, etc. ) can perform data communication with a second network node (e.g., a CN node, etc. ) via a first network node (e.g., a RAN node, etc. ) based on a UP solution, e.g., using a common tunnel or session for a device group including the first terminal device. In an embodiment, the first network node may establish the common tunnel between the first network node and the second network node. In another embodiment, the device group may be represented by a second terminal device selected by the first / second network node, and the common session may be established between the second terminal device and the second network node. In another embodiment, the first terminal device may access the first network node via a third terminal device, and the common session may be established between the third terminal device and the second network node. Compared to the CP based solution, the UP based solution can reduce communication overhead and improve resource utilization.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The disclosure itself, the preferable mode of use and further objectives are best understood by reference to the following detailed description of the embodiments when read in conjunction with the accompanying drawings, in which:

[0031] Figs. 1A-1E are diagrams illustrating exemplary connectivity topologies for A-IoT networks and devices according to some embodiments of the present disclosure;

[0032] Figs. 2A-2B are diagrams illustrating exemplary UP based solutions for network Topology 1 according to some embodiments of the present disclosure;

[0033] Fig. 3 is a diagram illustrating an exemplary UP based solution for network Topology 2 according to an embodiment of the present disclosure;

[0034] Figs. 4A-4E are flowcharts illustrating various methods according to some embodiments of the present disclosure;

[0035] Fig. 5 is a block diagram illustrating an apparatus according to an embodiment of the present disclosure;

[0036] Figs. 6A-6E are block diagrams illustrating various apparatuses according to some embodiments of the present disclosure;

[0037] Fig. 7 shows an example of a communication system in accordance with some embodiments;

[0038] Fig. 8 shows a UE in accordance with some embodiments;

[0039] Fig. 9 shows a network node in accordance with some embodiments; and

[0040] Fig. 10 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.DETAILED DESCRIPTION

[0041] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as new radio (NR) , long term evolution (LTE) , LTE-Advanced, wideband code division multiple access (WCDMA) , high-speed packet access (HSPA) , and so on. Furthermore, the communications between a terminal device and a network node in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , 4G, 4.5G, 5G communication protocols, and / or any other protocols either currently known or to be developed in the future.

[0042] The term “network node” refers to a network device in a communication network via which a terminal device accesses to the network and receives services therefrom. The network node may refer to a base station (BS) , an access point (AP) , a multi-cell / multicast coordination entity (MCE) , a controller or any other suitable device in a wireless communication network. The BS may be, for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNodeB or gNB) , a remote radio unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth.

[0043] Yet further examples of the network node comprise multi-standard radio (MSR) radio equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , base transceiver stations (BTSs) , transmission points, transmission nodes, positioning nodes and / or the like. More generally, however, the network node may represent any suitable device (or group of devices) capable, configured, arranged, and / or operable to enable and / or provide a terminal device access to a wireless communication network or to provide some service to a terminal device that has accessed to the wireless communication network.

[0044] The term “terminal device” refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device may refer to a mobile terminal, a user equipment (UE) , or other suitable devices. The UE may be, for example, a subscriber station, a portable subscriber station, a mobile station (MS) or an access terminal (AT) . The terminal device may include, but not limited to, portable computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, a mobile phone, a cellular phone, a smart phone, a tablet, a wearable device, a personal digital assistant (PDA) , a vehicle, and the like.

[0045] As yet another specific example, in an Internet of things (IoT) scenario, a terminal device may also be called an IoT device and represent a machine or other device that performs monitoring, sensing and / or measurements etc., and transmits the results of such monitoring, sensing and / or measurements etc. to another terminal device and / or a network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3rd generation partnership project (3GPP) context be referred to as a machine-type communication (MTC) device.

[0046] As one particular example, the terminal device may be a UE implementing the 3GPP narrow band Internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, e.g., refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment, for example, a medical instrument that is capable of monitoring, sensing and / or reporting etc. on its operational status or other functions associated with its operation.

[0047] As used herein, the terms “first” , “second” and so forth refer to different elements. The singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” as used herein, specify the presence of stated features, elements, and / or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. The term “based on” is to be read as “based at least in part on” . The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment” . The term “another embodiment” is to be read as “at least one other embodiment” . Other definitions, explicit and implicit, may be included below.

[0048] Recently work on ZE-IoT / A-IoT devices has started in 3GPP, referred to as “Ambient-IoT” . 3GPP technical report (TR) 22.840 V19.0.0 is being developed by SA1 to capture potential use cases, traffic scenarios, device constraints of A-IoT and to identify new potential service requirements as well as new key performance indicators (KPIs) .

[0049] Meanwhile, a study item at radio access network (RAN) plenary level RP-222685, “Study on Ambient IoT” is being carried out with a focus on the feasibility of meeting design targets for relevant use cases of A-IoT. The outcome is being reported in 3GPP TR 38.848 V18.0.0. Based on the outcome of the RAN study item, and the discussion during Release 19 (Rel-19) workshop during RAN#100 (RWS-230488) , a WG-level study item is expected to continue in Rel-19. In addition, depending on the progress and outcome of the WG-level study, a work item may be started during Rel-19 as well. It may be needed to have focused scope on issues such as device type (s) , deployment scenario (s) , topology option (s) , etc., and to address cross-TSG-dependencies, as well as a discussion about whether there is a strong need or it is feasible to convert the study and hence specify ambient IoT in Rel-19.

[0050] Deployment scenarios, use cases, services for A-IoT are described in clause 4 of 3GPP TR 38.848 V18.0.0. Two sets or levels of grouping are defined for use cases. The first, Grouping A, is on the basis of the deployment environment (s) described for a use case in 3GPP TR 22.840 V19.0.0, and the second, Grouping B, is on the basis of functionality / application described in 3GPP TR 22.840 V19.0.0.

[0051] These two groupings are then used to form representative use cases (rUCs) as follows, which are used in clause 4.2 “Deployment scenarios and connectivity topologies” of 3GPP TR 38.848 V18.0.0.

[0052] This results in the following mapping from SA1 use cases and traffic scenarios onto RAN rUCs as shown in Table 4.1.1-1 “Mapping between RAN representative use cases and SA1 use cases” in 3GPP TR 38.848 V18.0.0.

[0053] Figs. 1A-1E are diagrams illustrating exemplary connectivity topologies for A-IoT networks and devices according to some embodiments of the present disclosure. The exemplary connectivity topologies for A-IoT networks and devices are defined for the purposes of the study as described in 3GPP TR 38.848 V18.0.0. In all these topologies, the A-IoT device may be provided with a carrier wave (CW) from other node (s) either inside or outside the topology. The links in each topology may be bidirectional or unidirectional.

[0054] The topology in any of Figs. 1A-1E is described with respect to a single BS / UE / assisting node / intermediate node, but it can be appreciated that the BS / UE / assisting node / intermediate node as shown in Figs. 1A-1E may also be multiple BSs / UEs / assisting nodes / intermediate nodes, respectively. The mixture of indoor and outdoor placement of such nodes is regarded as a network implementation choice. Account may need to be taken of potential impact on device or node complexity. In the connectivity topologies, this does not imply the existence of multi-hop assisting or intermediate nodes. Different topologies are illustrated in below with respect to Figs. 1A-1E, respectively. ● Topology 1:

[0055] In Topology 1 as shown in Fig. 1A (which corresponds to Figure 1 / 4.2.1.1-1 in 3GPP TR 38.848 V18.0.0) , the A-IoT device directly and bidirectionally communicates with the BS. The communication between the BS and the A-IoT device includes A-IoT data and / or signaling. This topology includes the possibility that the BS transmitting to the A-IoT device is different from the BS receiving from the A-IoT device. ● Topology 2:

[0056] In Topology 2 as shown in Fig. 1B (which corresponds to Figure 2 / 4.2.1.2-1 in 3GPP TR 38.848 V18.0.0) , the A-IoT device communicates bidirectionally with the intermediate node between the A-IoT device and the BS. In this topology, the intermediate node can be a relay, an integrated access and backhaul (IAB) node, a UE, a repeater, etc. which is capable of A-IoT. The intermediate node transfers A-IoT data and / or signaling between the BS and the A-IoT device. ● Topology 3:

[0057] In Topology 3, the A-IoT device transmits data / signaling to the BS, and receives data / signaling from the assisting node (as shown in Fig. 1C which corresponds to Figure 3 / 4.2.1.3-1 “Topology 3 with downlink assistance” in 3GPP TR 38.848 V18.0.0) ; or the A-IoT device receives data / signaling from the BS and transmits data / signaling to the assisting node (as shown in Fig. 1D which corresponds to Figure 4 / 4.2.1.3-2 “Topology 3 with uplink assistance” in 3GPP TR 38.848 V18.0.0) . In this topology, the assisting node can be a relay, an IAB, a UE, a repeater, etc. which is capable of ambient IoT. ● Topology 4:

[0058] In Topology 4 as shown in Fig. 1E (which corresponds to Figure 5 / 4.2.1.4-1 in 3GPP TR 38.848 V18.0.0) , the A-IoT device communicates bidirectionally with the UE. The communication between the UE and the A-IoT device includes A-IoT data and / or signaling.

[0059] Deployment scenarios for A-IoT have been studied in 3GPP TR 38.848 V18.0.0 on the basis of a list of characteristics, and the representative use case (s) applicable to a scenario. There may be the following possible deployment scenarios for A-IoT: ● Deployment scenario 1: Device indoors, base station indoors. ● Deployment scenario 2: Device indoors, base station outdoors. ● Deployment scenario 3: Device indoors, UE-based reader. ● Deployment scenario 4: Device outdoors, base station outdoors. ● Deployment scenario 5: Device outdoors, UE-based reader.

[0060] A-IoT devices may be characterized in the study by 3GPP according to their energy storage capacity, and capability of generating RF signals for their transmissions. The study considers that a device has either: ● No energy storage at all; or ● Limited energy storage

[0061] Relying on these storage capacities, the study considers the following set of A-IoT devices: ● Device A: No energy storage, no independent signal generation / amplification, i.e.  backscattering transmission. ● Device B: Has energy storage, no independent signal generation, i.e. backscattering  transmission. Use of stored energy can include amplification for reflected signals. ● Device C: Has energy storage, has independent signal generation, i.e., active RF  components for transmission.

[0062] A limited energy storage can be different among implementations within Device B or implementations within Device C, and different between Device B and Device C. Such storage is expected to be order (s) of magnitude smaller than an NB-IoT device would typically include. Devices A, B, and C are able to demodulate control, data, etc. from the relevant entity in RAN according to the connectivity topology.

[0063] For A-IoT / ZE-IoT, 3GPP will target an IoT segment well below the existing cellular Internet of things (CIoT) technologies rather than replacement of existing 3GPP PLWA technologies. It is expected that together with simplifications in physical layer design, the higher layer (L2 / L3) design will also be much lighter weighted than the existing higher layer design in 3GPP, i.e., a minimal set of functionalities (both at access stratum (AS) and non-access stratum (NAS) levels) , which is even more simplified compared to that adopted for the existing CIoT technologies, may be used to operate A-IoT devices. One way of such simplifications is to design a communication protocol shifted from fully connection oriented with both NAS and radio resource control (RRC) connections between device and network to connectionless type of communication with or without RRC connections or even also no NAS connections between device and network so that the protocol and signaling overhead associated with the handshaking between device and network is minimized. This means that A-IoT devices do not setup and maintain an RRC connection with the network, also A-IoT devices do not setup and maintain AS context including (dedicated) radio bearer, logical channel, etc.

[0064] One way to implement connectionless communication is to employ message-based or self-contained transmission where context / control information associated with the signaling / data traffic is transmitted together with or right after the signaling / data traffic where in the latter case (i.e., the right after case) , there is no other transmission between the context / control information and the associated signaling / data traffic carrying information that is needed for reception of the signaling / data traffic. One such example is that in downlink (DL) the signaling / data traffic is transmitted within or right after the paging message.

[0065] As mentioned previously, A-IoT has been agreed to be as one study and / or work item for 3GPP Rel-19. One of the key use cases is inventory use case where a device is inventoried by the network. Upon reception of an inventory request message from a reader, the device needs to provide its ID (e.g., application ID, etc. ) and optionally other information such as device status to the application server (AS) . In addition, there are also use cases in which devices are required to provide some information (e.g., sensor data or response message, etc. ) to the AS. One of the options for the device to transmit such data to the network is the UP based solution. This solution requires setting up a connection on the UP. However, using the UP based solutions specified in the specification so far may be infeasible for an A-IoT device especially if the A-IoT device is a passive device limited by hardware considering, for example, the processing and storage capabilities of the A-IoT device. The device may have no sufficient power to establish and maintain a dedicated PDU session between the device and the CN. Therefore, it may be desirable to study how to design an efficient and / or simplified UP based solution for A-IoT devices. The UP based solution may be more efficient in case the A-IoT device is to report multiple times, e.g., read sensor data and report the information periodically.

[0066] Various exemplary embodiments of the present disclosure propose solutions to implement UP based communication between a device (e.g., a ZE-IoT, an A-IoT device, etc. ) and a network, e.g., in the case of Topology 1 as described with respect to Fig. 1A or Topology 2 as described with respect to Fig. 1B.

[0067] In accordance with exemplary embodiments in a first aspect of the solutions, a common tunnel between a RAN node and a CN may be used in Topology 1. In this option, a UP based data transmission mechanism may be applied based on a common tunnel / connection established between the RAN and the CN. The common tunnel / connection may represent a pair of association identifiers reserved at the CN and the RAN for a procedure like location reporting, when there is no dedicated connection for an A-IoT device. The common tunnel / connection may be SCTP like signaling connection, or it can be GTP-U tunnel connection. Each A-IoT device may be identified with a global unique ID in the system, or a unique ID within the RAN. Each network function (NF) requesting a location service may also be identified, e.g., by a routing ID. In this option, no Uu interface / connection is included in the tunnel. Since the data may be exchanged between devices and an application function (AF) or AIoT NF / AIoTF. The common tunnel may comprise two segments, where one segment of the tunnel is the connection between the RAN and a user plane function (UPF) , and another segment of the tunnel is the connection between the UPF and the AF or AIoT NF / AIoTF. In addition, UL and DL data may be transmitted / exchanged between the device and the network via the Uu interface (between the device and the RAN node) and the common tunnel (between the RAN and the CN) .

[0068] In accordance with exemplary embodiments in a second aspect of the solutions, a common PDU session based UP solution may be used in Topology 1. In this option, a common PDU session may be established between a device which represents a device group and the CN (e.g., session management function (SMF) , UPF, AIoTF or AIoT NF, etc. ) . This common PDU session may be shared by all devices in the same group / the same area. In an embodiment, one device which is capable of establishing a PDU session may be selected (e.g., by the CN and / or a RAN node such as a gNB) in the group / area, to represent the group. This device can establish a PDU session for the group following the legacy NAS procedure. The NAS message / signaling in this case may be extended to include an indicator indicating that the PDU session can serve all devices in the same group / the same area rather than for an individual device. In another embodiment, if there is not any device in the group / the area which is capable of establishing a PDU session, the CN or RAN node may therefore configure a virtual device in the group, which represents the group / the area. This virtual device can establish the PDU session for the group following the legacy NAS procedure. The NAS message / signaling in this case may be extended to include an indicator indicating that the PDU session can serve all devices in the same group / the same area rather than for an individual device. This virtual device may not generate its own data or receive data from the CN. Devices sharing this common PDU session can transmit / receive data to / from the network (e.g., an AF, etc. ) .

[0069] In accordance with exemplary embodiments in a third aspect of the solutions, a common PDU session based UP solution may be used in Topology 2. In this option, an intermediate UE can establish a PDU session or reuse an existing PDU session which can be shared for all A-IoT devices accessing the network via the intermediate UE. In an embodiment, the intermediate UE as a reader may be triggered to establish a PDU session towards a CN node (via an RAN node such as a gNB) upon reception of an inventory request signaling from the CN node or the RAN node towards one or multiple devices. The PDU session can be shared for all devices in the same group / area.

[0070] Many advantages may be achieved by applying the proposed solutions. For example, devices may be able to transmit or receive data to / from the CN / AF, using a UP based solution, which may give lower overhead than a control plane (CP) based solution. The UP based solution may be implemented on a common tunnel / PDU session. In this way, no dedicated tunnel / session may be needed for each device, which can reduce the device’s complexity.

[0071] More details of the proposed solutions of the present disclosure will be described below in connection with various exemplary embodiments. Use cases with ultra-low power devices, ZE-IoT devices or A-IoT devices are considered or assumed in some exemplary embodiments. However, the proposed solutions may not be limited to such devices and can be applicable to other service / device classes or categories.

[0072] It can be appreciated that the term “RAN node” may refer to a network node or a UE. Examples of network nodes may include NodeB, BS, MSR radio node such as MSR BS, eNodeB, gNodeB, MeNB, SeNB, location measurement unit (LMU) , integrated access backhaul (IAB) node, network controller, radio network controller (RNC) , base station controller (BCS) , relay, IAB, repeater, donor node controlling relay, base transceiver station (BTS) , central unit (e.g., in a gNB) , distributed unit (e.g., in a gNB) , baseband unit, centralized baseband, C-RAN, access point (AP) , transmission point, transmission node, transmission reception point (TRP) , RRU, RRH, nodes in distributed antenna system (DAS) , core network node (e.g., MCS, MME, etc. ) , O&M, OSS, SON, positioning node (e.g., E-SMLC) , etc. In particular, in an A-IoT scenario, the RAN node may comprise an intermediate node / UE (e.g., relay UE, IAB, repeater, etc. ) and assisting node / UE (e.g., relay UE, IAB, repeater etc. ) .

[0073] It can be appreciated that the terms “polling” , “poll” , “paging” , “page” , “inventory” , “query” and “interrogate” may be used to represent one or more than one signal transmitted by a network node broadcast wise or specially to a dedicated UE. The purpose of the signal is to facilitate / serve / manage / command one or more than one UE to synchronize to the network node (e.g., DL / UL synchronize to a reference time / frame / symbol, or synchronize to one or more than one signal which the UE receives from the network node, or synchronize based on a pre-defined rule) , receive DL data, response and transmit UL data correctly in intended resources. The content of such signal may be a particular reference signal or a signal carrying control information and / or data. Such signal may be transmitted periodically or be periodically configured by the network node.

[0074] In accordance with exemplary embodiments, the terms “A-IoT UE” , “A-IoT device” , “device” and “UE” may be used interchangeably without losing the meaning. In addition, the terms “intermediate node” , “intermediate UE” and “UE” may also be used interchangeably without losing the meaning.

[0075] In accordance with an exemplary embodiment, the term “data” may stand for A-IoT data exchanged between an A-IoT device and a CN node (e.g., an AIoTF or AIoT NF which may be responsible for A-IoT service handling) . The A-IoT data may comprise, but not limited to, at least one of the following information elements: ● Device ID (including CN ID, e.g., subscription permanent identifier (SUPI) , subscription  concealed identifier (SUCI) , 5G globally unique temporary identifier (5G-GUTI) or Application ID, e.g., evolved packet core (EPC) , etc. ) . ● Other information such as device status, device measurement results and / or device  location. ● Sensor data. ● Actuator control information including actuator command sent by the network and / or the  actuator execution result. Note: Data may be somewhat different depending on the service. ● Inventory: a gNB / reader may initiate an inventory procedure over the air interface and  may report the results of the inventory to the CN. ● UL data (or “read” ) : two alternatives are possible: - A data field may be included in an inventory report, e.g., a record in the inventory  report may not only contain a device ID but also an associated data field, e.g. a status report. - Device reporting per device, e.g., for the reporting of sensor data or an event. This is  more similar to legacy random access, but may be achieved also for passive devices by a common carrier wave opportunity which may only be used by the device with new data in the UL buffer. ● DL Command (or “write” ) : two alternatives are possible: - Common transmission in the UP tunnel. Similar to the inventory plus data field report  above but instead in the DL, and the data field may contain either a command for the device or some data to be written to the associated device. The gNB / reader may be responsible for delivery of this to each device. (No necessarily Ack per device to the CN, but the gNB / reader can report back to the CN which devices it successfully managed to transmit to) . - Device command per device. For example, the data / command may be received per  device by the gNB / reader.

[0076] In accordance with exemplary embodiments, it may be assumed that a device applies a CP based option (e.g., data is embedded in CP signaling sent to an access and mobility management function (AMF) , and the AMF forwards the data to the UPF / AF) to report its ID and optionally some additional data to the CN during an initial inventory procedure, when there is no common UP tunnel / connection established yet. As soon as the common UP tunnel / connection has been established, any device in the same area / the same group can transmit / receive data on the common UP tunnel / connection.

[0077] Exemplary embodiments in the first and second aspects of the solutions are described below for the case of a gNB operating as a reader in Topology 1 of Fig. 1A.

[0078] Solution I -Common tunnel between RAN nodes and the CN without Uu connection.

[0079] In this solution, an UP option based on a common tunnel / connection between the RAN and the CN is applied. The common connection may represent a pair of association identifiers reserved / assigned at the CN and the RAN for the procedure like location reporting, when there is no dedicated connection for an A-IoT device. The common connection may be an SCTP like signaling connection, or it can be a GTP-U tunnel connection. Each A-IoT device may be identified with a global unique ID in the system, or a unique ID within the RAN node. Each network function requesting a location service may also be identified, e.g., by a routing ID.

[0080] In this solution, no dedicated Uu connection is included in the tunnel. Since the data may be exchanged between devices and an AF or AIoT NF / AIoTF, the common tunnel may comprise two segments, where one segment of the tunnel is the connection between the RAN and a UPF, and another segment of the tunnel is the connection between the UPF and the AF or AIoT NF / AIoTF. In an embodiment, the common tunnel / connection may be triggered to be established by the gNB / RAN node towards the CN when at least one of the conditions is met: ● The gNB has received a signal from the CN indicating that the gNB needs to initiate an  inventory procedure or send a command to one or multiple devices while there is no common tunnel / connection established yet. ● The gNB has been configured by the CN or operation administration and maintenance  (OAM) (including operation support system / business support system (OSS / BSS) ) to operate as a reader towards one or multiple devices. ● The gNB has received a signal from one device indicating it may receive command (s)  that may also be received by other device (s) (i.e., the same command is sent to multiple devices) while there is no common tunnel / connection established yet. ● The gNB has received a signal from the CN to establish the common tunnel / connection,  for instance, when the common tunnel / connection is per area and the CN may already have established a common tunnel / connection with other gNB (s) in the area.

[0081] In an embodiment, for a gNB operating as a reader towards one or multiple devices, the gNB may be triggered (e.g., upon reception of an inventory / query command from the CN) to establish a tunnel / connection between the gNB and the CN node (e.g., an AMF, an SMF, a UPF or a CN node such as AIoTF or AIoT NF) which is responsible for A-IoT service handling) for transmitting / receiving data to / from the CN. The connection may be established per device group, area, service, gNB, etc., but unlike the legacy operation which is per device. Devices in the same group / area, using the same service, or managed / served by the same gNB can share the same connection. In practice, this means that for the data transmissions, the device may not refer to a previously set up device-specific tunnel (cf. legacy connection setup) , instead no setup is required by the device (e.g., a UE, etc. ) upon data transmission but the device or the gNB may then for each transmission append a device identifier (or a device specific identifier that is pre-configured in the device or that the device receives from the network) with the data for routing over the common tunnel in the CN.

[0082] In an embodiment on UL data transmission, when the gNB receives data from a device, the gNB may build a packet / frame containing a header and a payload. For example, the header may contain at least one of the below information elements: ● A source ID: e.g., the device’s ID. This ID may be needed if the UL data transmission is  triggered by a group DL command targeting multiple devices. In case the UL data transmission is triggered by a dedicated DL command only targeting one device, the source ID may be optional (i.e., the UL data transmission can be performed without the source ID) . The source ID can also be omitted in case the payload is required to include enough information for the AF to differentiate the message from other devices and the segment of the tunnel between the UPF and the AF is the only option for the UPF to send the UL packet. In this case, the CN can indicate to the gNB whether there is a need for the gNB to add the source ID in the header of UL packets. ● Additional information: e.g., location information can be added by the gNB in case the  gNB can differentiate the devices’ locations, e.g., the common tunnel may serve devices in different locations. The location information can be condensed and may imply that the UPF needs to perform a mapping towards the AF.

[0083] In an embodiment, the payload may comprise data part as described in the above. After that, the gNB can map / send the frame / packet to the destination CN node via the common connection / tunnel.

[0084] In another embodiment, the device by itself includes its ID in the payload which is not encrypted. In this case, the ID in the header may not be needed.

[0085] In an embodiment on DL data transmission, the DL data may be initiated from the AF or CN node, e.g., AIoTF or AIoT NF towards a device. In such case, the data may be contained in a data frame which contains a destination ID, e.g., the device’s ID or a group ID in the header and / or the payload. The data frame may be transmitted on the common connection / tunnel. The data frame may be first transmitted from the AF or AIoTF / AIoT NF to the UPF. Then, the data frame may be transmitted from the UPF to the gNB. The destination ID within the data frame can be built by the AF or AIoTF / AIoT NF when sending to the UPF, or by the UPF when sending to the gNB. The gNB can further transmit the data part via the Uu interface (e.g., included in a medium access control (MAC) control element (CE) (MAC CE) ) to the device associated with the device ID or the group ID.

[0086] Fig. 2A is a diagram illustrating an exemplary UP based solution for network Topology 1 according to an embodiment of the present disclosure. According to the common CN tunnel based UP solution shown in Fig. 2A, a gNB may receive an inventory command (e.g., towards one or multiple devices in a device group) from a CN. The inventory command may trigger the gNB to establish a common connection / tunnel towards the CN. The common connection / tunnel can be shared by the one or multiple devices to transmit or receive data to / from the CN via the gNB.

[0087] In an embodiment, for a common tunnel, it may be assumed, if the user sends: ● Only ID - Option A: No tunnel is needed between the UPF and the RAN node, i.e., the CP is  used. Note: The ID (s) (which may be a device ID or an application ID) may be a function of  or mapped to a CN ID (e.g., SUPI, SUCI, TMSI, GUTI, etc. ) which may be used in an inventory procedure to identify an inventoried device / user. - Option B: The ID (s) may be considered as part of the payload which can be delivered  using the UP solution, for non-limiting scenarios as below: ■ The ID which is mapped to / function of a CN ID. ■ The ID which is non-mappable to / not function of a CN ID. ■ Both of above. - In above new ID type can be considered, which may be based on RFID technology,  e.g., EPC, part of EPC, RN16, handle ID, etc. ● Data in addition to ID (Option A / B) : Common tunnel may be needed (the UP solution) . - Further different policies can be defined. For example, a threshold can be defined if  the data volume is small (e.g., below the threshold) or a user is handling very low data amount (e.g., few information bits) , e.g., related to product expiration or manufacturing, then the CP solution may be used. This type of information can be indicated during the capability exchange, inventory or registration procedure. If the data volume to be handled is above the threshold, then the UP solution is preferred or utilized as an example.

[0088] In an embodiment, when the ID (s) is part of the payload in the received UL transmission, the RAN node may send the received UL payload to the specifically predefined UPF in case the inventory command is sent to the RAN node by an AMF / AIoTF (i.e., the DL inventory command may be sent via CP while the UL response is sent via the UP) or triggered by the RAN node itself.

[0089] As an additional embodiment, the gNB receiving an inventory command can determine whether an already established tunnel can be re-used based on the content (e.g., a CN tunnel ID, or a device group ID, or home / realm of the device, or realm of the triggering AF) of the message received from the CN (e.g., AIoTF) . If there is already an established common tunnel that can be re-used, then the gNB may make a mapping of the information in the request to the tunnel (e.g., additional information in the device report used for tunnel association, e.g. device specific information like home network ID / realm) and continue to perform the inventory.

[0090] In an embodiment, one or more options or policies or rules as below can be defined to set up the UP solution. ● The usage type of the device or a group of devices is configured in the CN, e.g., as part of  subscription information. This can indicate that UP is preferred. ● When a device connects to the RAN node / CN, it can indicate capability which can  include handling of data type or use case. - If the device requires data handling, e.g., during an inventory procedure or part of an  access procedure for an inventoried user / device, then the network can make sure to consider the device, e.g., part of a device group to be served with the common tunnel based UP solution. - If not indicating handling of data (Option I) , e.g., only IDs (CN IDs or IDs mappable  to the CN IDs) are required to be exchanged or notified with the network, a very specific inventory use case (equivalent to paging or registration or subset of registration) , then the network may not consider these devices for the common tunnel / connection (UP solution) between the RAN node and the UPF. For Option II scenario with ID handling, the UP solution may be preferred or required as the ID (s) can be delivered as part of the payload. - In an embodiment, in the common tunnel based UP solution, a mapping may be  needed for a given connection associated with a specific device, e.g., if the tunnel identifier (TEID) is associated with the common tunnel (belong to a group of devices) , then a device or user specific flag or ID can be incorporated in the header for UPF connection or relate transmission identification. ■ In an embodiment, the mapping may be related to the request, i.e. the reader can  provide an ID of the request e.g. in broadcast information, and the device can copy the request ID into the report, and the reader then can map the device request to the established common tunnel. ■ The usage of a common tunnel can be made transparent to the device, and the  policy to establish the common tunnel can be based on the AF request, e.g., if the AF sends an inventory / command to a set of devices and also provides an address for where the responses are to be received, which is to be used as the endpoint of the tunnel segment between the UPF and the AF. In this case, the CN may use the AF input to request a common tunnel to be set up towards the gNB and the gNB may use the previously described logic to provide responses from the devices into the established common tunnel.

[0091] Solution II -Common PDU session based UP solution.

[0092] In this solution, a common PDU session may be established between a device which represents a device group and a CN (e.g., an AIoTF or AIoT NF, SMF and UPF, etc. ) . This common PDU session can be shared by all devices in the same group / the same area.

[0093] In an embodiment, a device which is capable of establishing a PDU session may be selected (e.g., by the CN and / or the gNB) in the group / area, to represent the group. This device may establish the PDU session for the group following the legacy NAS procedure. The NAS message / signaling in this case may be extended to include an indicator indicating that the PDU session serves all devices in the same group / the same area rather than for an individual device. The device may be determined with respect to various criteria, e.g., at least one of below: ● The device which is capable of establishing a PDU session. ● The device from which the gNB receives the highest signal strength / power. ● The device from which the gNB receives the earliest signal. ● The device which the gNB determines has the low moving state or static. ● The device has strongest capability, e.g., highest output power or highest energy / memory  storge, and can generate its own UL transmission, etc.

[0094] Alternatively or additionally, the CN and / or the gNB may select multiple UEs to represent the group, then several PDU sessions regarding such multiple UEs can serve the group. If one representing UE moves to another RAN node or area, there may be still other common PDU sessions backup. Further, if the UE representing the group moves out or is going to move out, such that its PDU session is not or will be not available for the group, then one approach is selecting another UE in the area to set up a new PDU session for the group. In this case, there may be interruptions to on-going transmissions. Another approach is that the gNB and / or the CN maintains the PDU sessions for a while until on-going transmission is completed, after that the gNB and / or the CN can determine another UE to set up a new PDU session. In another approach, the gNB may store the data when its associated common PDU session is released and forward the stored data to the new common PDU session (initiated by another UE) when the new common PDU session is established.

[0095] In an embodiment, if there is not any device in the group / the area which is capable of establishing a PDU session, the CN node and / or the gNB may therefore configure a virtual device in the group, which represents the group / the area. This virtual device may establish the PDU session for the group following the legacy NAS procedure. The NAS message / signaling in this case can be extended to include an indicator indicating that the PDU session serves all devices in the same group / the same area rather than for an individual device. This virtual device may not generate its own data or receive data from the CN.

[0096] In accordance with an exemplary embodiment, the device (which is selected to establish the PDU session) may be triggered to establish the PDU session when at least one of the following conditions is met: ● The device supports registration and PDU session establishment procedures. The device  may perform the registration procedure (e.g., during the initial inventory procedure that the device needs to report its ID to the CN) . After the registration procedure is completed, the PDU session can be established following the legacy procedure. ● The device receives the initial inventory request. The device may be triggered to establish  the PDU session even the device does not perform the registration procedure.

[0097] In an embodiment, when the common PDU session shared by all devices in the same group is established by one device in the group, the other devices may also be added into the common PDU session when e.g., performing inventory. The group information may be indicated in the inventory command and only the devices in the group may response and then be added into the common PDU session, or a device may indicate its group in the response and it may be added into the common PDU session in case it belongs to the group associated with the common PDU session. The CN (e.g., an SMF / AIoTF) may store the IDs of devices that are put into the common PDU session, and remove a device from the common PDU session when e.g., the device is inventoried by another gNB which is not associated with the common PDU session or the UPF does not receive a certain number of expected UL transmissions / responses from the device. A common PDU session may be released only when no devices are associated with it (e.g., for a certain time) .

[0098] In an embodiment on UL transmission, when the gNB receives data from a device other than the device which has established the PDU session, the gNB may build a data frame containing the received data and send the data frame via the common PDU session to the CN. The data frame may contain the device ID, which can be used by the CN to derive the data source when receiving the data frame.

[0099] In an embodiment on DL transmission, DL data may be initiated from the AF or CN node, e.g., AIoTF / AIoT NF towards a device. In such case, the data may be contained in a data frame which contains a destination ID, e.g., the device’s ID or the group ID in the header and / or the payload. The data frame can be transmitted on the common PDU session. The data frame may be first transmitted from the AF or AIoTF / AIoT NF to the UPF. Then, the data frame may be transmitted from the UPF to the gNB. The destination ID within the data frame can be built by the AF or AIoTF / AIoT NF when sending to the UPF, or by the UPF when sending to the gNB. The gNB may further transmit the data part via the Uu interface (e.g., included in a MAC CE) to the device associated with the device ID or group ID.

[0100] Fig. 2B is a diagram illustrating an exemplary UP based solution for network Topology 1 according to another embodiment of the present disclosure. According to the common PDU session based UP solution shown in Fig. 2B, a device (e.g., in a device group) may be triggered by an inventory command from a CN to establish a common PDU session with the CN. The common PDU session can be shared by different devices (e.g., in the device group) to transmit or receive data to / from the CN via a gNB.

[0101] Exemplary embodiments in the third aspect of the solutions are described below for the case of an intermediate UE operating as a reader in Topology 2 of Fig. 1B. In this solution, the intermediate UE can establish a PDU session which can be shared for all devices which access the network via the intermediate UE.

[0102] In an embodiment, the intermediate UE as a reader may be triggered to establish a PDU session towards the CN node (via the gNB) upon reception of an inventory request signaling from the CN or the gNB towards one or multiple devices. The PDU session can be shared for all devices in the same area / group (which access the network via the intermediate UE) . In another embodiment, it may be possible to let the existing PDU session to be shared by all devices (which access the network via the intermediate UE) without establishing a new one. The PDU session may be dedicated for the A-IoT traffic of the devices or shared by the intermediate UE and the device. The dedicated PDU session can use a dedicated single network slice selection assistance information (S-NSSAI) and / or data network name (DNN) provided to the UE e.g. in UE route selection policy (URSP) rules. It may be possible that the reader can establish multiple PDU sessions for devices with different groups, for example, associated with group IDs.

[0103] In an embodiment on UL transmission, when the intermediate UE receives data from a device, the intermediate UE may build a data frame containing the received data and send the data frame via the common PDU session to the CN. The data frame may contain the device ID, which can be used by the CN or the AF to derive the data source when receiving the data frame.

[0104] In an embodiment on DL transmission, DL data may be initiated from the AF or the CN node, e.g., AIoTF / AIoT NF towards a device. In such case, the data may be contained in a data frame which contains a destination ID, e.g., the device’s ID or group ID in the header and / or the payload. The data frame can be transmitted on the common PDU session. The data frame may be first transmitted from the AF or AIoTF / AIoT NF to the UPF. Then, the data frame may be transmitted from the UPF to the intermediate UE. The destination ID within the data frame can be built by the AF or AIoTF / AIoT NF when sending to the UPF, or by the UPF when sending to the gNB. The intermediate UE may further transmit the data part (e.g., included in a MAC CE) to the device associated with the device ID or group ID.

[0105] Fig. 3 is a diagram illustrating an exemplary UP based solution for network Topology 2 according to an embodiment of the present disclosure. According to the common PDU session based UP solution in Topology 2 shown in Fig. 3, an intermediate UE may be triggered by an inventory command from a CN to establish a common PDU session with the CN. The common PDU session can be shared by different devices (e.g., in a device group) to transmit or receive data to / from the CN via the intermediate UE and a gNB.

[0106] In an embodiment, the intermediate UE may establish a PDU session or use an existing PDU session. The intermediate UE may perform the inventory and command towards the devices as per the request from the CN, and then add the reports into one or more application layer messages that are sent to the AF via the UP of the PDU session.

[0107] In another embodiment, when the intermediate UE moves between gNBs, the intermediate UE may indicate to the CN (e.g., AIoTF / AMF, etc. ) , for example, as an additional step in a handover procedure for RRC_CONNECTED mobility as well as in RRC_INACTIVE mobility. In this case, the CN may reconsider if the intermediate UE can or need be still an intermediate node (reader) after the move and thus can schedule the inventory and DL command accordingly.

[0108] Some exemplary embodiments on data transmission on Uu interface are also described herein. In an embodiment, a device may be triggered to transmit data to a reader via one or more of the following signaling alternatives or a new alternative inspired by at least one of the signaling formats as below: A MAC CE; A L1 signaling; A MAC Header Element; and A MAC PDU or MAC Sub-PDU.

[0109] In an embodiment, the device may use a MAC CE to report its device ID to the reader, where the MAC CE may be a newly defined MAC CE, e.g., named as A-IoT data MAC CE.

[0110] In another embodiment, the devices may use a MAC header element for conveying the device ID in which a dynamic or fixed size payload or several payloads may be associated. In this embodiment, a “header only” variant can be exemplified.

[0111] In another embodiment, the device may use a MAC PDU or MAC Sub-PDU to convey the device ID. For this case, the header may additionally convey the PDU-type, payload content / type, length and / or other information of the payload multiplexed / piggybacked to this PDU.

[0112] In an embodiment, the device’s MAC entity may trigger the A-IoT data MAC CE or other as described above, upon reception of an inventory request message from the reader. The trigger may in one alternative be considered pending or cancelled and may be cancelled when the device MAC has obtained an occasion to transmit the A-IoT data device ID. Optionally, the trigger event or pending device ID transmission may be cancelled only when the device has received a response message from the reader after the device’s MAC entity has transmitted the MAC CE and / or other device identifier to the reader.

[0113] Some exemplary embodiments on security protection of user data (including ID report in inventory case) are also described herein. In an embodiment, user data exchanged between a device and a network including device ID report during inventory may be protected by UP security between the device and a RAN node, if available, which may be established / setup, e.g., during or after a registration procedure. In this case, security operation can be performed for all UP data provided to the AS layer, e.g., at RRC or packet data convergence protocol (PDCP) or MAC sublayer.

[0114] In an embodiment, the device and the RAN node may maintain the security context including a context ID and security materials (e.g., keys, algorithms, parameters, etc. ) . Alternative or in addition to the RAN node storing the security context, the CN (e.g., AIoTF / AFM, etc. ) can keep the AS security context. In this case, the RAN node may need to obtain the security context from the network / CN using the context ID. In an embodiment, the context ID can be the same as the device ID in the RAN scope, e.g., being allocated by the RAN node during random access (similar to Handle in RFID, I-RNTI in NR) . In another embodiment, the context ID can be the CN allocated ID (e.g., temporary mobile subscriber identity (TMSI) such as 5G-S-TMSI, etc. ) .

[0115] In a UL message (e.g., a first UL message with UL data / signaling) during the random access, the device may provide the context ID, so that the RAN node can locate / fetch the security context, e.g., directly from the previous RAN node or via the CN in case of mobility, or from the CN in case the security context is stored at the CN.

[0116] In an embodiment, the security context / material can be set up by the RAN and / or can be determined by the CN and provided to the RAN node after the device is authenticated / authorized successfully in the CN, e.g., in the registration procedure. The security context / material can be derived from or independent from the NAS security context. In an embodiment, the AS sublayer handling security operation (e.g., RRC or PDCP or MAC) can maintain the COUNT or sequence number of packet (s)  / PDU (s) as freshness for the ciphering / integrity protection function.

[0117] It is noted that some embodiments of the present disclosure are mainly described in relation to 5G / NR specifications being used as non-limiting examples for certain exemplary network configurations and system deployments. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does naturally not limit the present disclosure in any way. Rather, any other system configuration or radio technologies may equally be utilized as long as exemplary embodiments described herein are applicable.

[0118] Fig. 4A is a flowchart illustrating a method 410 according to some embodiments of the present disclosure. The method 410 illustrated in Fig. 4A may be performed by a first terminal device (e.g., an ultra-low power device, a ZE-IoT device, an A-IoT device such as an A-IoT UE, etc. ) or an apparatus communicatively coupled to the first terminal device. In accordance with an exemplary embodiment, the first terminal device may be configured to communicate with a network node directly or via an intermediate device.

[0119] According to the exemplary method 410 illustrated in Fig. 4A, the first terminal device may perform UP based communication for data of the first terminal device via a common tunnel for a device group or a common session for the device group, as shown in block 414. The UP based communication may be between the first terminal device and a second network node via at least a first network node. The first terminal device may belong to the device group. In an embodiment, the common tunnel may comprise a SCTP connection or a GTP-U connection. In another embodiment, the common session may be a common PDU session.

[0120] In accordance with an exemplary embodiment, the common tunnel may be a common CN tunnel. In an embodiment, the common CN tunnel may include a first segment between the first network node and a UPF and a second segment between the UPF and the second network node. In an embodiment, the common tunnel may be between the first network node and the second network node and established per device group, per area, per service, and / or per serving node.

[0121] In accordance with an exemplary embodiment, the first terminal device may optionally generate the data of the first terminal device, as shown in block 412. The data of the first terminal device may include UL data of the first terminal device to be transmitted to the first network node in a predefined format. In an embodiment, the predefined format may comprise one or more of: a MAC CE; physical layer (L1) signaling; a MAC header element; a MAC PDU; and a MAC Sub-PDU.

[0122] In accordance with an exemplary embodiment, the first terminal device performing the UP based communication for the data of the first terminal device via the common tunnel may comprise: transmitting the UL data of the first terminal device to the first network node. The UL data of the first terminal device may be forwarded in a first packet from the first network node to the second network node via the common tunnel.

[0123] In accordance with an exemplary embodiment, the first terminal device performing the UP based communication for the data of the first terminal device via the common tunnel may comprise: receiving DL data of the first terminal device from the first network node. The DL data of the first terminal device may be transmitted in a second packet from the second network node to the first network node via the common tunnel.

[0124] In accordance with an exemplary embodiment, the common session may be between a second terminal device representing the device group and the second network node.

[0125] In accordance with an exemplary embodiment, the first terminal device performing the UP based communication for the data of the first terminal device via the common session may comprise: transmitting the UL data of the first terminal device to the first network node. The UL data of the first terminal device may be forwarded in a third packet from the first network node to the second network node via the common session.

[0126] In accordance with an exemplary embodiment, the first terminal device performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving DL data of the first terminal device from the first network node. The DL data of the first terminal device may be transmitted in a fourth packet from the second network node to the first network node via the common session.

[0127] In accordance with an exemplary embodiment, the common session may be between a third terminal device and the second network node. In an embodiment, the third terminal device may be an intermediate device between the device group and the first network node.

[0128] In accordance with an exemplary embodiment, the first terminal device performing the UP based communication for the data of the first terminal device via the common session may comprise: transmitting the UL data of the first terminal device to the third terminal device. The UL data of the first terminal device may be forwarded in a fifth packet from the third terminal device towards the second network node through the first network node via the common session.

[0129] In accordance with an exemplary embodiment, the first terminal device performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving DL data of the first terminal device from the third terminal device. The DL data of the first terminal device may be transmitted in a sixth packet from the second network node towards the third terminal device through the first network node via the common session.

[0130] In accordance with an exemplary embodiment, the data of the first terminal device may be associated with identification information. In an embodiment, the identification information may comprise one or more of: an identifier of the first terminal device; an identifier of the device group; location information of the first terminal device; and an identifier of a message for the data of the first terminal device.

[0131] In accordance with an exemplary embodiment, the UP based communication for the data of the first terminal device may be protected at least by UP security between the first terminal device and the first network node.

[0132] Fig. 4B is a flowchart illustrating a method 420 according to some embodiments of the present disclosure. The method 420 illustrated in Fig. 4B may be performed by a second terminal device (e.g., an ultra-low power device, a ZE-IoT device, an A-IoT device such as an A-IoT UE, etc. ) or an apparatus communicatively coupled to the second terminal device. In accordance with an exemplary embodiment, the second terminal device may be configured to communicate with a network node directly or via an intermediate device.

[0133] According to the exemplary method 420 illustrated in Fig. 4B, the second terminal device may establish a common session (e.g., a common PDU session, etc. ) between the second terminal device and a second network node, as shown in block 422. The common session can be shared by different devices in a device group for UP based communication between the different devices and the second network node via a first network node. The device group may be represented by the second terminal device.

[0134] In accordance with an exemplary embodiment, the second terminal device may be a device in the device group and capable of establishing a session.

[0135] In accordance with an exemplary embodiment, the second terminal device may be selected to represent the device group by the first network node and / or the second network node according to one or more of: the second terminal device being capable of establishing a session; the second terminal device being a device from which the first network node receives the highest signal strength and / or power, compared to other devices in the device group; the second terminal device being a device from which the first network node receives the earliest signal, compared to the other devices in the device group; the second terminal device having a low moving state or being static; and the second terminal device having the strongest capability to generate data to be transmitted, compared to the other devices in the device group.

[0136] In accordance with an exemplary embodiment, the second terminal device may be a virtual device configured for the device group, when there is no device in the device group which is capable of establishing a session.

[0137] In accordance with an exemplary embodiment, the second terminal device may establish the common session according to a NAS procedure. In an embodiment, a NAS message associated with the common session may indicate that the common session can be shared by all devices in the device group.

[0138] In accordance with an exemplary embodiment, the second terminal device may establish the common session in response to one or more of: registration of the second terminal device to the second network node; and reception of a request for establishing the common session.

[0139] In accordance with an exemplary embodiment, the second terminal device may be one of a set of devices representing the device group which establish a set of common sessions for the device group.

[0140] In accordance with an exemplary embodiment, the second terminal device may optionally perform UP based communication for data of the second terminal device via the common session, as shown in block 424. The UP based communication for the data of the second terminal device may be between the second terminal device and the second network node via the first network node.

[0141] Fig. 4C is a flowchart illustrating a method 430 according to some embodiments of the present disclosure. The method 430 illustrated in Fig. 4C may be performed by a third terminal device (e.g., an intermediate UE, a relay UE, an assisting device, etc. ) or an apparatus communicatively coupled to the third terminal device. In accordance with an exemplary embodiment, the third terminal device may be configured to act as an intermediate device for relaying communications between a network node and one or more devices (e.g., ZE-IoT devices, A-IoT devices, etc. ) .

[0142] According to the exemplary method 430 illustrated in Fig. 4C, the third terminal device may establish a common session (e.g., a common PDU session, etc. ) between the third terminal device and a second network node, as shown in block 432. The common session can be shared by different devices in a device group for UP based communication between the different devices and the second network node via the third terminal device and a first network node. The third terminal device may be an intermediate device between the device group and the first network node.

[0143] In accordance with an exemplary embodiment, the device group may include one or more devices which may access the first network node via the third terminal device. In accordance with another exemplary embodiment, the device group may include the third terminal device and the one or more devices which may access the first network node via the third terminal device.

[0144] In accordance with an exemplary embodiment, the third terminal device may also establish one or more other common sessions for one or more other device groups served by the third terminal device, respectively. In an embodiment, the third terminal device may establish the common session in response to: reception of a message for one or more devices in the device group from the first network node and / or the second network node.

[0145] In accordance with an exemplary embodiment, the third terminal device may optionally perform UP based communication for data of a first terminal device via the common session, as shown in block 434. The UP based communication for the data of the first terminal device may be between the first terminal device and the second network node via the third terminal device and the first network node.

[0146] In accordance with an exemplary embodiment, the third terminal device performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving UL data of the first terminal device from the first terminal device; generating a packet which may include the UL data of the first terminal device and identification information; and transmitting the packet towards the second network node through the first network node via the common session.

[0147] In accordance with an exemplary embodiment, the third terminal device performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving another packet (which may include DL data of the first terminal device and identification information) from the second network node through the first network node via the common session; and transmitting the DL data of the first terminal device to the first terminal device.

[0148] In accordance with an exemplary embodiment, the identification information may comprise one or more of: an identifier of the first terminal device; an identifier of the device group; location information of the first terminal device; and an identifier of a message for the data of the first terminal device.

[0149] Fig. 4D is a flowchart illustrating a method 440 according to some embodiments of the present disclosure. The method 440 illustrated in Fig. 4D may be performed by a first network node (e.g., a base station, a gNB, a control node, etc. ) or an apparatus communicatively coupled to the first network node. In accordance with an exemplary embodiment, the first network node may be configured to communicate with one or more terminal devices directly or via relaying and facilitate communication between the one or more terminal devices and a CN node.

[0150] According to the exemplary method 440 illustrated in Fig. 4D, the first network node may perform UP based communication for data of a first terminal device via a common tunnel (e.g., a SCTP connection or a GTP-U connection, etc. ) for a device group or a common session (e.g., a common PDU session, etc. ) for the device group, as shown in block 444. The UP based communication may be between the first terminal device and a second network node via at least the first network node. The first terminal device may belong to the device group. In an embodiment, the first network node may be a RAN node. In another embodiment, the second network node may be a CN node.

[0151] In accordance with an exemplary embodiment, the common tunnel may be a common CN tunnel which may include a first segment between the first network node and a UPF and a second segment between the UPF and the second network node.

[0152] In accordance with an exemplary embodiment, the first network node may optionally establish the common tunnel between the first network node and the second network node, as shown in block 442. In an embodiment, the first network node may establish the common tunnel in response to one or more of: reception of a message indicating that the first network node needs to initiate a communication procedure for one or more devices; reception of a message indicating that the first network node needs to transmit a message to the one or more devices; reception of a message indicating that the first network node needs to receive a message for the one or more devices; reception of a request for establishing the common tunnel; and configuration of the first network node to operate as a reader for the one or more devices.

[0153] In accordance with an exemplary embodiment, the common tunnel may be an already established tunnel available for the UP based communication. In an embodiment, the common tunnel may be established per device group, per area, per service, and / or per serving node.

[0154] In accordance with an exemplary embodiment, the first network node may perform the UP based communication for the data of the first terminal device via the common tunnel in response to one or more of: an amount of the data of the first terminal device being above a threshold; usage type information of the first terminal device indicating that a tunnel based UP communication is preferred; usage type information of the device group indicating that the tunnel based UP communication is preferred; subscription information of the first terminal device indicating that the tunnel based UP communication is preferred; capability information of the first terminal device indicating that the tunnel based UP communication is preferred; a data delivery requirement of the first terminal device indicating that the tunnel based UP communication is preferred; and a request for the tunnel based UP communication by an AF.

[0155] In accordance with an exemplary embodiment, the first network node performing the UP based communication for the data of the first terminal device via the common tunnel may comprise: receiving UL data of the first terminal device from the first terminal device; generating a first packet which may include the UL data of the first terminal device and identification information; and transmitting the first packet to the second network node via the common tunnel.

[0156] In accordance with an exemplary embodiment, the first network node performing the UP based communication for the data of the first terminal device via the common tunnel may comprise: receiving a second packet (which may include DL data of the first terminal device and identification information) from the second network node via the common tunnel; and transmitting the DL data of the first terminal device to the first terminal device.

[0157] In accordance with an exemplary embodiment, the common session may be established between a second terminal device representing the device group and the second network node.

[0158] In accordance with an exemplary embodiment, the first network node and / or the second network node may select the second terminal device to represent the device group according to one or more of: the second terminal device being capable of establishing a session; the second terminal device being a device from which the first network node receives the highest signal strength and / or power, compared to other devices in the device group; the second terminal device being a device from which the first network node receives the earliest signal, compared to the other devices in the device group; the second terminal device having a low moving state or being static; and the second terminal device having the strongest capability to generate data to be transmitted, compared to the other devices in the device group. In an embodiment, a set of devices including the second terminal device may be selected by the first network node and / or the second network node to represent the device group and establish a set of common sessions for the device group.

[0159] In accordance with an exemplary embodiment, the second terminal device may be a virtual device configured for the device group by the first network node and / or the second network node, when there is no device in the device group which is capable of establishing a session.

[0160] In accordance with an exemplary embodiment, the first network node performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving UL data of the first terminal device from the first terminal device; generating a third packet which may include the UL data of the first terminal device and identification information; and transmitting the third packet to the second network node via the common session.

[0161] In accordance with an exemplary embodiment, the first network node performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving a fourth packet (which may include DL data of the first terminal device and identification information) from the second network node via the common session; and transmitting the DL data of the first terminal device to the first terminal device.

[0162] In accordance with an exemplary embodiment, the common session may be established between a third terminal device and the second network node. In an embodiment, the third terminal device may be an intermediate device between the device group and the first network node.

[0163] In accordance with an exemplary embodiment, the first network node performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving a fifth packet (which may include UL data of the first terminal device and identification information) from the third terminal device via the common session; and transmitting the fifth packet to the second network node via the common session.

[0164] In accordance with an exemplary embodiment, the first network node performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving a sixth packet (which may include DL data of the first terminal device and identification information) from the second network node via the common session; and transmitting the sixth packet to the third terminal device via the common session. In an embodiment, the DL data of the first terminal device may be forwarded from the third terminal device to the first terminal device.

[0165] In accordance with an exemplary embodiment, the identification information may comprise one or more of: an identifier of the first terminal device; an identifier of the device group; location information of the first terminal device; and an identifier of a message for the data of the first terminal device.

[0166] Fig. 4E is a flowchart illustrating a method 450 according to some embodiments of the present disclosure. The method 450 illustrated in Fig. 4E may be performed by a second network node (e.g., a CN node such as AMF, SMF, UPF, AIoTF, AIoT NF, etc. ) or an apparatus communicatively coupled to the second network node. In accordance with an exemplary embodiment, the second network node may be configured to communicate with one or more terminal devices via a RAN node (e.g., the first network node as described with respect to Fig. 4D) and perform service handling.

[0167] According to the exemplary method 450 illustrated in Fig. 4E, the second network node may perform UP based communication for data of a first terminal device via a common tunnel (e.g., a SCTP connection or a GTP-U connection, etc. ) for a device group or a common session (e.g., a common PDU session, etc. ) for the device group, as shown in block 454. The UP based communication may be between the first terminal device and the second network node via at least a first network node (e.g., a RAN node, etc. ) . The first terminal device may belong to the device group.

[0168] In accordance with an exemplary embodiment, the common tunnel may be a common CN tunnel including a first segment between the first network node and a UPF and a second segment between the UPF and the second network node.

[0169] In accordance with an exemplary embodiment, the second network node performing the UP based communication for the data of the first terminal device via the common tunnel may comprise: receiving a first packet from the first network node via the common tunnel. The first packet may include UL data of the first terminal device and identification information.

[0170] In accordance with an exemplary embodiment, the second network node performing the UP based communication for the data of the first terminal device via the common tunnel may comprise: transmitting a second packet to the first network node via the common tunnel. The second packet may include DL data of the first terminal device and identification information.

[0171] In accordance with an exemplary embodiment, the common session may be established between a second terminal device representing the device group and the second network node. In an embodiment, the second terminal device may be one of a set of devices selected from the device group by the first network node and / or the second network node. In another embodiment, the second terminal device may be a virtual device configured for the device group by the first network node and / or the second network node.

[0172] In accordance with an exemplary embodiment, the second network node performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving a third packet from the first network node via the common session. The third packet may include UL data of the first terminal device and identification information.

[0173] In accordance with an exemplary embodiment, the second network node performing the UP based communication for the data of the first terminal device via the common session may comprise: transmitting a fourth packet to the first network node via the common session. The fourth packet may include DL data of the first terminal device and identification information.

[0174] In accordance with an exemplary embodiment, the common session may be established between a third terminal device and the second network node. In an embodiment, the third terminal device may be an intermediate device between the device group and the first network node.

[0175] In accordance with an exemplary embodiment, the second network node performing the UP based communication for the data of the first terminal device via the common session may comprise: receiving a fifth packet from the third terminal device through the first network node via the common session. The fifth packet may include UL data of the first terminal device and identification information.

[0176] In accordance with an exemplary embodiment, the second network node performing the UP based communication for the data of the first terminal device via the common session may comprise: transmitting a sixth packet towards the third terminal device through the first network node via the common session. The sixth packet may include DL data of the first terminal device and identification information.

[0177] In accordance with an exemplary embodiment, the second network node may optionally transmit, towards one or more devices in the device group via at least the first network node, a message for triggering establishment of the common tunnel and / or the common session, as shown in block 452.

[0178] The various blocks shown in Figs. 4A-4E may be viewed as method steps, and / or as operations that result from operation of computer program code, and / or as a plurality of coupled logic circuit elements constructed to carry out the associated function (s) . The schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.

[0179] Fig. 5 is a block diagram illustrating an apparatus 500 according to various embodiments of the present disclosure. As shown in Fig. 5, the apparatus 500 may comprise one or more processors such as processor 501 and one or more memories such as memory 502 storing computer program codes 503. The memory 502 may be non-transitory machine / processor / computer readable storage medium. In accordance with some exemplary embodiments, the apparatus 500 may be implemented as an integrated circuit chip or module that can be plugged or installed into a first terminal device as described with respect to Fig. 4A, or a second terminal device as described with respect to Fig. 4B, or a third terminal device as described with respect to Fig. 4C, or a first network node as described with respect to Fig. 4D, or a second network node as described with respect to Fig. 4E. In such cases, the apparatus 500 may be implemented as a first terminal device as described with respect to Fig. 4A, or a second terminal device as described with respect to Fig. 4B, or a third terminal device as described with respect to Fig. 4C, or a first network node as described with respect to Fig. 4D, or a second network node as described with respect to Fig. 4E.

[0180] In some implementations, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with Fig. 4A. In other implementations, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with Fig. 4B. In other implementations, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with Fig. 4C. In other implementations, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with Fig. 4D. In other implementations, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform any operation of the method as described in connection with Fig. 4E. Alternatively or additionally, the one or more memories 502 and the computer program codes 503 may be configured to, with the one or more processors 501, cause the apparatus 500 at least to perform more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

[0181] Fig. 6A is a block diagram illustrating an apparatus 610 according to some embodiments of the present disclosure. As shown in Fig. 6A, the apparatus 610 may comprise a performing unit 611 and optionally a generating unit 612. In an exemplary embodiment, the apparatus 610 may be implemented in a first terminal device. The performing unit 611 may be operable to carry out the operation in block 414, and the generating unit 612 may be operable to carry out the operation in block 412. Optionally, the performing unit 611 and / or the generating unit 612 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

[0182] Fig. 6B is a block diagram illustrating an apparatus 620 according to some embodiments of the present disclosure. As shown in Fig. 6B, the apparatus 620 may comprise an establishing unit 621 and optionally a performing unit 622. In an exemplary embodiment, the apparatus 620 may be implemented in a second terminal device. The establishing unit 621 may be operable to carry out the operation in block 422, and the performing unit 622 may be operable to carry out the operation in block 424. Optionally, the establishing unit 621 and / or the performing unit 622 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

[0183] Fig. 6C is a block diagram illustrating an apparatus 630 according to some embodiments of the present disclosure. As shown in Fig. 6C, the apparatus 630 may comprise an establishing unit 631 and optionally a performing unit 632. In an exemplary embodiment, the apparatus 630 may be implemented in a third terminal device. The establishing unit 631 may be operable to carry out the operation in block 432, and the performing unit 632 may be operable to carry out the operation in block 434. Optionally, the establishing unit 631 and / or the performing unit 632 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

[0184] Fig. 6D is a block diagram illustrating an apparatus 640 according to some embodiments of the present disclosure. As shown in Fig. 6D, the apparatus 640 may comprise a performing unit 641 and optionally an establishing unit 642. In an exemplary embodiment, the apparatus 640 may be implemented in a first network node. The performing unit 641 may be operable to carry out the operation in block 444, and the establishing unit 642 may be operable to carry out the operation in block 442. Optionally, the performing unit 641 and / or the establishing unit 642 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

[0185] Fig. 6E is a block diagram illustrating an apparatus 650 according to some embodiments of the present disclosure. As shown in Fig. 6E, the apparatus 650 may comprise a performing unit 651 and optionally a transmitting unit 652. In an exemplary embodiment, the apparatus 650 may be implemented in a second network node. The performing unit 651 may be operable to carry out the operation in block 454, and the transmitting unit 652 may be operable to carry out the operation in block 452. Optionally, the performing unit 651 and / or the transmitting unit 652 may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

[0186] Fig. 7 shows an example of a communication system 700 in accordance with some embodiments.

[0187] In the example, the communication system 700 includes a telecommunication network 702 that includes an access network 704, such as a radio access network (RAN) , and a core network 706, which includes one or more core network nodes 708. The access network 704 includes one or more access network nodes, such as network nodes 710A and 710B (one or more of which may be generally referred to as network nodes 710) , or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 702 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 702 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 702, including one or more network nodes 710 and / or core network nodes 708.

[0188] Examples of an ORAN network node include an open radio unit (O-RU) , an open distributed unit (O-DU) , an open central unit (O-CU) , including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP) , a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp) , or any combination thereof (the adjective “open” designating support of an ORAN specification) . The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 710 facilitate direct or indirect connection of user equipment (UE) , such as by connecting UEs 712A, 712B, 712C, and 712D (one or more of which may be generally referred to as UEs 712) to the core network 706 over one or more wireless connections.

[0189] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 700 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0190] The UEs 712 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 710 and other communication devices. Similarly, the network nodes 710 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 712 and / or with other network nodes or equipment in the telecommunication network 702 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 702.

[0191] In the depicted example, the core network 706 connects the network nodes 710 to one or more host computing systems, such as host 716. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 706 includes one more core network nodes (e.g., core network node 708) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 708. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC) , Mobility Management Entity (MME) , Home Subscriber Server (HSS) , Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Authentication Server Function (AUSF) , Subscription Identifier De-concealing function (SIDF) , Unified Data Management (UDM) , Security Edge Protection Proxy (SEPP) , Network Exposure Function (NEF) , and / or a User Plane Function (UPF) .

[0192] The host 716 may be under the ownership or control of a service provider other than an operator or provider of the access network 704 and / or the telecommunication network 702. The host 716 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0193] As a whole, the communication system 700 of Fig. 7 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM) ; Universal Mobile Telecommunications System (UMTS) ; Long Term Evolution (LTE) , and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G) ; wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi) ; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax) , Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0194] In some examples, the telecommunication network 702 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 702 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 702. For example, the telecommunications network 702 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)  / Massive IoT services to yet further UEs.

[0195] In some examples, the UEs 712 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 704 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 704. Additionally, a UE may be configured for operating in single-or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC) , such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio –Dual Connectivity (EN-DC) .

[0196] In the example, the hub 714 communicates with the access network 704 to facilitate indirect communication between one or more UEs (e.g., UE 712C and / or 712D) and network nodes (e.g., network node 710B) . In some examples, the hub 714 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 714 may be a broadband router enabling access to the core network 706 for the UEs. As another example, the hub 714 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 710, or by executable code, script, process, or other instructions in the hub 714. As another example, the hub 714 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 714 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 714 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 714 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 714 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices.

[0197] The hub 714 may have a constant / persistent or intermittent connection to the network node 710B. The hub 714 may also allow for a different communication scheme and / or schedule between the hub 714 and UEs (e.g., UE 712C and / or 712D) , and between the hub 714 and the core network 706. In other examples, the hub 714 is connected to the core network 706 and / or one or more UEs via a wired connection. Moreover, the hub 714 may be configured to connect to an M2M service provider over the access network 704 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 710 while still connected via the hub 714 via a wired or wireless connection. In some embodiments, the hub 714 may be a dedicated hub –that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 710B. In other embodiments, the hub 714 may be a non-dedicated hub –that is, a device which is capable of operating to route communications between the UEs and network node 710B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0198] Fig. 8 shows a UE 800 in accordance with some embodiments. The UE 800 presents additional details of some embodiments of the UE 712 of Fig. 7. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA) , wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE) , vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP) , including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0199] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC) , vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , or vehicle-to-everything (V2X) . In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller) . Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter) .

[0200] The UE 800 includes processing circuitry 802 that is operatively coupled via a bus 804 to an input / output interface 806, a power source 808, a memory 810, a communication interface 812, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Fig. 8. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0201] The processing circuitry 802 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 810. The processing circuitry 802 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs) , application specific integrated circuits (ASICs) , etc. ) ; programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP) , together with appropriate software; or any combination of the above. For example, the processing circuitry 802 may include multiple central processing units (CPUs) .

[0202] In the example, the input / output interface 806 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 800. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc. ) , a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0203] In some embodiments, the power source 808 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet) , photovoltaic device, or power cell, may be used. The power source 808 may further include power circuitry for delivering power from the power source 808 itself, and / or an external power source, to the various parts of the UE 800 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 808. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 808 to make the power suitable for the respective components of the UE 800 to which power is supplied.

[0204] The memory 810 may be or be configured to include memory such as random access memory (RAM) , read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 810 includes one or more application programs 814, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 816. The memory 810 may store, for use by the UE 800, any of a variety of various operating systems or combinations of operating systems.

[0205] The memory 810 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID) , flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM) , synchronous dynamic random access memory (SDRAM) , external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) , such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC) , integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card. ’ The memory 810 may allow the UE 800 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 810, which may be or comprise a device-readable storage medium.

[0206] The processing circuitry 802 may be configured to communicate with an access network or other network using the communication interface 812. The communication interface 812 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 822. The communication interface 812 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network) . Each transceiver may include a transmitter 818 and / or a receiver 820 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth) . Moreover, the transmitter 818 and receiver 820 may be coupled to one or more antennas (e.g., antenna 822) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0207] In the illustrated embodiment, communication functions of the communication interface 812 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA) , Wideband Code Division Multiple Access (WCDMA) , GSM, LTE, New Radio (NR) , UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP) , synchronous optical networking (SONET) , Asynchronous Transfer Mode (ATM) , QUIC, Hypertext Transfer Protocol (HTTP) , and so forth.

[0208] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 812, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature) , random (e.g., to even out the load from reporting from several sensors) , in response to a triggering event (e.g., when moisture is detected an alert is sent) , in response to a request (e.g., a user initiated request) , or a continuous stream (e.g., a live video feed of a patient) .

[0209] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0210] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal-or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV) , and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 800 shown in Fig. 8.

[0211] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0212] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0213] Fig. 9 shows a network node 900 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) , base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs) ) , O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU) .

[0214] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs) , sometimes referred to as Remote Radio Heads (RRHs) . Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS) .

[0215] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , base transceiver stations (BTSs) , transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs) , Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs) ) , and / or Minimization of Drive Tests (MDTs) .

[0216] The network node 900 includes a processing circuitry 902, a memory 904, a communication interface 906, and a power source 908. The network node 900 may be composed of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc. ) , which may each have their own respective components. In certain scenarios in which the network node 900 comprises multiple separate components (e.g., BTS and BSC components) , one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 900 may be configured to support multiple radio access technologies (RATs) . In such embodiments, some components may be duplicated (e.g., separate memory 904 for different RATs) and some components may be reused (e.g., a same antenna 910 may be shared by different RATs) . The network node 900 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 900, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 900.

[0217] The processing circuitry 902 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 900 components, such as the memory 904, to provide network node 900 functionality.

[0218] In some embodiments, the processing circuitry 902 includes a system on a chip (SOC) . In some embodiments, the processing circuitry 902 includes one or more of radio frequency (RF) transceiver circuitry 912 and baseband processing circuitry 914. In some embodiments, the radio frequency (RF) transceiver circuitry 912 and the baseband processing circuitry 914 may be on separate chips (or sets of chips) , boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 912 and baseband processing circuitry 914 may be on the same chip or set of chips, boards, or units.

[0219] The memory 904 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM) , read-only memory (ROM) , mass storage media (for example, a hard disk) , removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD) ) , and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 902. The memory 904 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 902 and utilized by the network node 900. The memory 904 may be used to store any calculations made by the processing circuitry 902 and / or any data received via the communication interface 906. In some embodiments, the processing circuitry 902 and memory 904 is integrated.

[0220] The communication interface 906 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 906 comprises port (s)  / terminal (s) 916 to send and receive data, for example to and from a network over a wired connection. The communication interface 906 also includes radio front-end circuitry 918 that may be coupled to, or in certain embodiments a part of, the antenna 910. Radio front-end circuitry 918 comprises filters 920 and amplifiers 922. The radio front-end circuitry 918 may be connected to an antenna 910 and processing circuitry 902. The radio front-end circuitry may be configured to condition signals communicated between antenna 910 and processing circuitry 902. The radio front-end circuitry 918 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 918 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 920 and / or amplifiers 922. The radio signal may then be transmitted via the antenna 910. Similarly, when receiving data, the antenna 910 may collect radio signals which are then converted into digital data by the radio front-end circuitry 918. The digital data may be passed to the processing circuitry 902. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0221] In certain alternative embodiments, the network node 900 does not include separate radio front-end circuitry 918, instead, the processing circuitry 902 includes radio front-end circuitry and is connected to the antenna 910. Similarly, in some embodiments, all or some of the RF transceiver circuitry 912 is part of the communication interface 906. In still other embodiments, the communication interface 906 includes one or more ports or terminals 916, the radio front-end circuitry 918, and the RF transceiver circuitry 912, as part of a radio unit (not shown) , and the communication interface 906 communicates with the baseband processing circuitry 914, which is part of a digital unit (not shown) .

[0222] The antenna 910 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 910 may be coupled to the radio front-end circuitry 918 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 910 is separate from the network node 900 and connectable to the network node 900 through an interface or port.

[0223] The antenna 910, communication interface 906, and / or the processing circuitry 902 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 910, the communication interface 906, and / or the processing circuitry 902 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0224] The power source 908 provides power to the various components of network node 900 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component) . The power source 908 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 900 with power for performing the functionality described herein. For example, the network node 900 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 908. As a further example, the power source 908 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0225] Embodiments of the network node 900 may include additional components beyond those shown in Fig. 9 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 900 may include user interface equipment to allow input of information into the network node 900 and to allow output of information from the network node 900. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 900. In some embodiments providing a core network node, such as core network node 708 of Fig. 7, some components, such as the radio front-end circuitry 918 and the RF transceiver circuitry 912 may be omitted.

[0226] Fig. 10 is a block diagram illustrating a virtualization environment 1000 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host) , then the node may be entirely virtualized. In some embodiments, the virtualization environment 1000 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0227] Applications 1002 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) are run in the virtualization environment 1000 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0228] Hardware 1004 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1006 (also referred to as hypervisors or virtual machine monitors (VMMs) ) , provide VMs 1008A and 1008B (one or more of which may be generally referred to as VMs 1008) , and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1006 may present a virtual operating platform that appears like networking hardware to the VMs 1008.

[0229] The VMs 1008 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1006. Different embodiments of the instance of a virtual appliance 1002 may be implemented on one or more of VMs 1008, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV) . NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0230] In the context of NFV, a VM 1008 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1008, and that part of hardware 1004 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1008 on top of the hardware 1004 and corresponds to the application 1002.

[0231] Hardware 1004 may be implemented in a standalone network node with generic or specific components. Hardware 1004 may implement some functions via virtualization. Alternatively, hardware 1004 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1010, which, among others, oversees lifecycle management of applications 1002. In some embodiments, hardware 1004 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1012 which may alternatively be used for communication between hardware nodes and radio units.

Claims

1.A method (410) performed by a first terminal device, comprising:performing (414) user plane, UP, based communication for data of the first terminal device via a common tunnel for a device group or a common session for the device group, wherein the UP based communication is between the first terminal device and a second network node via at least a first network node, and the first terminal device belongs to the device group.2.The method according to claim 1, wherein the common tunnel is a common core network, CN, tunnel including:a first segment between the first network node and a user plane function, UPF; anda second segment between the UPF and the second network node.3.The method according to claim 1 or 2, wherein the common tunnel is between the first network node and the second network node and established per device group, per area, per service, and / or per serving node.4.The method according to any of claims 1-3, wherein performing the UP based communication for the data of the first terminal device via the common tunnel comprises:transmitting uplink, UL, data of the first terminal device to the first network node, wherein the UL data of the first terminal device is forwarded in a first packet from the first network node to the second network node via the common tunnel; and / orreceiving downlink, DL, data of the first terminal device from the first network node, wherein the DL data of the first terminal device is transmitted in a second packet from the second network node to the first network node via the common tunnel.5.The method according to any of claims 1-4, wherein the common session is between a second terminal device representing the device group and the second network node.6.The method according to claim 5, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:transmitting UL data of the first terminal device to the first network node, wherein the UL data of the first terminal device is forwarded in a third packet from the first network node to the second network node via the common session; and / orreceiving DL data of the first terminal device from the first network node, wherein the DL data of the first terminal device is transmitted in a fourth packet from the second network node to the first network node via the common session.7.The method according to any of claims 1-4, wherein the common session is between a third terminal device and the second network node, and the third terminal device is an intermediate device between the device group and the first network node.8.The method according to claim 7, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:transmitting UL data of the first terminal device to the third terminal device, wherein the UL data of the first terminal device is forwarded in a fifth packet from the third terminal device towards the second network node through the first network node via the common session; and / orreceiving DL data of the first terminal device from the third terminal device, wherein the DL data of the first terminal device is transmitted in a sixth packet from the second network node towards the third terminal device through the first network node via the common session.9.The method according to any of claims 1-8, wherein the data of the first terminal device is associated with identification information comprising one or more of:an identifier of the first terminal device;an identifier of the device group;location information of the first terminal device; andan identifier of a message for the data of the first terminal device.10.The method according to any of claims 1-9, further comprising:generating (412) the data of the first terminal device, wherein the data of the first terminal device includes UL data of the first terminal device to be transmitted to the first network node in a predefined format.11.The method according to claim 10, wherein the predefined format comprises one or more of:a medium access control, MAC, control element, CE;physical layer signaling;a MAC header element;a MAC protocol data unit, PDU; anda MAC Sub-PDU.12.The method according to any of claims 1-11, wherein the UP based communication for the data of the first terminal device is protected at least by UP security between the first terminal device and the first network node.13.The method according to any of claims 1-12, wherein the common tunnel comprises a stream control transmission protocol, SCTP, connection or a general packet radio service tunneling protocol user plane, GTP-U, connection.14.The method according to any of claims 1-13, wherein the common session is a common PDU session.15.A method (420) performed by a second terminal device, comprising:establishing (422) a common session between the second terminal device and a second network node, wherein the common session can be shared by different devices in a device group for user plane, UP, based communication between the different devices and the second network node via a first network node, and the device group is represented by the second terminal device.16.The method according to claim 15, wherein the second terminal device is a device in the device group and capable of establishing a session.17.The method according to claim 15 or 16, wherein the second terminal device is selected to represent the device group by the first network node and / or the second network node according to one or more of:the second terminal device being capable of establishing a session;the second terminal device being a device from which the first network node receives the highest signal strength and / or power, compared to other devices in the device group;the second terminal device being a device from which the first network node receives the earliest signal, compared to the other devices in the device group;the second terminal device having a low moving state or being static; andthe second terminal device having the strongest capability to generate data to be transmitted, compared to the other devices in the device group.18.The method according to any of claims 15-17, further comprising:performing (424) UP based communication for data of the second terminal device via the common session, wherein the UP based communication for the data of the second terminal device is between the second terminal device and the second network node via the first network node.19.The method according to claim 15, wherein the second terminal device is a virtual device configured for the device group, when there is no device in the device group which is capable of establishing a session.20.The method according to any of claims 15-19, wherein the second terminal device establishes the common session according to a non-access stratum, NAS, procedure, and a NAS message associated with the common session indicates that the common session can be shared by all devices in the device group.21.The method according to any of claims 15-20, wherein the second terminal device establishes the common session in response to one or more of:registration of the second terminal device to the second network node; andreception of a request for establishing the common session.22.The method according to any of claims 15-21, wherein the second terminal device is one of a set of devices representing the device group which establish a set of common sessions for the device group.23.The method according to any of claims 15-22, wherein the common session is a common protocol data unit, PDU, session.24.A method (430) performed by a third terminal device, comprising:establishing (432) a common session between the third terminal device and a second network node, wherein the common session can be shared by different devices in a device group for user plane, UP, based communication between the different devices and the second network node via the third terminal device and a first network node, and the third terminal device is an intermediate device between the device group and the first network node.25.The method according to claim 24, wherein the device group includes:one or more devices which access the first network node via the third terminal device; orthe third terminal device and the one or more devices which access the first network node via the third terminal device.26.The method according to claim 24 or 25, wherein the third terminal device also establishes one or more other common sessions for one or more other device groups served by the third terminal device, respectively.27.The method according to any of claims 24-26, wherein the third terminal device establishes the common session in response to: reception of a message for one or more devices in the device group from the first network node and / or the second network node.28.The method according to any of claims 24-27, further comprising:performing (434) UP based communication for data of a first terminal device via the common session, wherein the UP based communication for the data of the first terminal device is between the first terminal device and the second network node via the third terminal device and the first network node.29.The method according to claim 28, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving uplink, UL, data of the first terminal device from the first terminal device;generating a packet which includes the UL data of the first terminal device and identification information; andtransmitting the packet towards the second network node through the first network node via the common session.30.The method according to claim 28 or 29, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving another packet from the second network node through the first network node via the common session, wherein the another packet includes downlink, DL, data of the first terminal device and identification information; andtransmitting the DL data of the first terminal device to the first terminal device.31.The method according to claim 29 or 30, wherein the identification information comprises one or more of:an identifier of the first terminal device;an identifier of the device group;location information of the first terminal device; andan identifier of a message for the data of the first terminal device.32.The method according to any of claims 24-31, wherein the common session is a common protocol data unit, PDU, session.33.A method (440) performed by a first network node, comprising:performing (444) user plane, UP, based communication for data of a first terminal device via a common tunnel for a device group or a common session for the device group, wherein the UP based communication is between the first terminal device and a second network node via at least the first network node, and the first terminal device belongs to the device group.34.The method according to claim 33, wherein the common tunnel is a common core network, CN, tunnel including:a first segment between the first network node and a user plane function, UPF; anda second segment between the UPF and the second network node.35.The method according to claim 33 or 34, further comprising:establishing (442) the common tunnel between the first network node and the second network node.36.The method according to claim 35, wherein the first network node establishes the common tunnel in response to one or more of:reception of a message indicating that the first network node needs to initiate a communication procedure for one or more devices;reception of a message indicating that the first network node needs to transmit a message to the one or more devices;reception of a message indicating that the first network node needs to receive a message for the one or more devices;reception of a request for establishing the common tunnel; andconfiguration of the first network node to operate as a reader for the one or more devices.37.The method according to claim 33 or 34, wherein the common tunnel is an already established tunnel available for the UP based communication.38.The method according to any of claims 33-37, wherein the common tunnel is established per device group, per area, per service, and / or per serving node.39.The method according to any of claims 33-38, wherein the first network node performs the UP based communication for the data of the first terminal device via the common tunnel in response to one or more of:an amount of the data of the first terminal device being above a threshold;usage type information of the first terminal device indicating that a tunnel based UP communication is preferred;usage type information of the device group indicating that the tunnel based UP communication is preferred;subscription information of the first terminal device indicating that the tunnel based UP communication is preferred;capability information of the first terminal device indicating that the tunnel based UP communication is preferred;a data delivery requirement of the first terminal device indicating that the tunnel based UP communication is preferred; anda request for the tunnel based UP communication by an application function, AF.40.The method according to any of claims 33-39, wherein performing the UP based communication for the data of the first terminal device via the common tunnel comprises:receiving uplink, UL, data of the first terminal device from the first terminal device;generating a first packet which includes the UL data of the first terminal device and identification information; andtransmitting the first packet to the second network node via the common tunnel.41.The method according to any of claims 33-40, wherein performing the UP based communication for the data of the first terminal device via the common tunnel comprises:receiving a second packet from the second network node via the common tunnel, wherein the second packet includes downlink, DL, data of the first terminal device and identification information; andtransmitting the DL data of the first terminal device to the first terminal device.42.The method according to any of claims 33-41, wherein the common session is established between a second terminal device representing the device group and the second network node.43.The method according to claim 42, wherein the second terminal device is selected to represent the device group by the first network node and / or the second network node according to one or more of:the second terminal device being capable of establishing a session;the second terminal device being a device from which the first network node receives the highest signal strength and / or power, compared to other devices in the device group;the second terminal device being a device from which the first network node receives the earliest signal, compared to the other devices in the device group;the second terminal device having a low moving state or being static; andthe second terminal device having the strongest capability to generate data to be transmitted, compared to the other devices in the device group.44.The method according to claim 42 or 43, wherein a set of devices including the second terminal device are selected by the first network node and / or the second network node to represent the device group and establish a set of common sessions for the device group.45.The method according to claim 42, wherein the second terminal device is a virtual device configured for the device group by the first network node and / or the second network node, when there is no device in the device group which is capable of establishing a session.46.The method according to any of claims 42-45, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving UL data of the first terminal device from the first terminal device;generating a third packet which includes the UL data of the first terminal device and identification information; andtransmitting the third packet to the second network node via the common session.47.The method according to any of claims 42-46, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving a fourth packet from the second network node via the common session, wherein the fourth packet includes DL data of the first terminal device and identification information; andtransmitting the DL data of the first terminal device to the first terminal device.48.The method according to any of claims 33-41, wherein the common session is established between a third terminal device and the second network node, and the third terminal device is an intermediate device between the device group and the first network node.49.The method according to claim 48, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving a fifth packet from the third terminal device via the common session, wherein the fifth packet includes UL data of the first terminal device and identification information; andtransmitting the fifth packet to the second network node via the common session.50.The method according to claim 48 or 49, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving a sixth packet from the second network node via the common session, wherein the sixth packet includes DL data of the first terminal device and identification information; andtransmitting the sixth packet to the third terminal device via the common session, wherein the DL data of the first terminal device is forwarded from the third terminal device to the first terminal device.51.The method according to claim 40, 41, 46, 47, 49 or 50, wherein the identification information comprises one or more of:an identifier of the first terminal device;an identifier of the device group;location information of the first terminal device; andan identifier of a message for the data of the first terminal device.52.The method according to any of claims 33-51, wherein the common tunnel comprises a stream control transmission protocol, SCTP, connection or a general packet radio service tunneling protocol user plane, GTP-U, connection.53.The method according to any of claims 33-52, wherein the common session is a common protocol data unit, PDU, session.54.The method according to any of claims 33-53, wherein the first network node is a radio access network, RAN, node, and / or the second network node is a CN node.55.A method (450) performed by a second network node, comprising:performing (454) user plane, UP, based communication for data of a first terminal device via a common tunnel for a device group or a common session for the device group, wherein the UP based communication is between the first terminal device and the second network node via at least a first network node, and the first terminal device belongs to the device group.56.The method according to claim 55, further comprising:transmitting (452) , towards one or more devices in the device group via at least the first network node, a message for triggering establishment of the common tunnel and / or the common session.57.The method according to claim 55 or 56, wherein the common tunnel is a common core network, CN, tunnel including:a first segment between the first network node and a user plane function, UPF; anda second segment between the UPF and the second network node.58.The method according to any of claims 55-57, wherein performing the UP based communication for the data of the first terminal device via the common tunnel comprises:receiving a first packet from the first network node via the common tunnel, wherein the first packet includes uplink, UL, data of the first terminal device and identification information; and / ortransmitting a second packet to the first network node via the common tunnel, wherein the second packet includes downlink, DL, data of the first terminal device and identification information.59.The method according to any of claims 55-58, wherein the common session is established between a second terminal device representing the device group and the second network node.60.The method according to claim 59, wherein the second terminal device is one of a set of devices selected from the device group by the first network node and / or the second network node; or the second terminal device is a virtual device configured for the device group by the first network node and / or the second network node.61.The method according to claim 59 or 60, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving a third packet from the first network node via the common session, wherein the third packet includes UL data of the first terminal device and identification information; and / ortransmitting a fourth packet to the first network node via the common session, wherein the fourth packet includes DL data of the first terminal device and identification information.62.The method according to any of claims 55-58, wherein the common session is established between a third terminal device and the second network node, and the third terminal device is an intermediate device between the device group and the first network node.63.The method according to claim 62, wherein performing the UP based communication for the data of the first terminal device via the common session comprises:receiving a fifth packet from the third terminal device through the first network node via the common session, wherein the fifth packet includes UL data of the first terminal device and identification information; and / ortransmitting a sixth packet towards the third terminal device through the first network node via the common session, wherein the sixth packet includes DL data of the first terminal device and identification information.64.The method according to claim 58, 61 or 63, wherein the identification information comprises one or more of:an identifier of the first terminal device;an identifier of the device group;location information of the first terminal device; andan identifier of a message for the data of the first terminal device.65.The method according to any of claims 55-64, wherein the common session is a common protocol data unit, PDU, session.66.The method according to any of claims 55-65, wherein the first network node is a radio access network, RAN, node, and / or the second network node is a CN node.67.A first terminal device (500) , comprising:one or more processors (501) ; andone or more memories (502) comprising computer program codes (503) ,the one or more memories (502) and the computer program codes (503) configured to, with the one or more processors (501) , cause the first terminal device (500) at least to:perform user plane, UP, based communication for data of the first terminal device via a common tunnel for a device group or a common session for the device group, wherein the UP based communication is between the first terminal device and a second network node via at least a first network node, and the first terminal device belongs to the device group.68.The first terminal device according to claim 67, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the first terminal device to perform the method according to any one of claims 2-14.69.A second terminal device (500) , comprising:one or more processors (501) ; andone or more memories (502) comprising computer program codes (503) ,the one or more memories (502) and the computer program codes (503) configured to, with the one or more processors (501) , cause the second terminal device (500) at least to:establish a common session between the second terminal device and a second network node, wherein the common session can be shared by different devices in a device group for user plane, UP, based communication between the different devices and the second network node via a first network node, and the device group is represented by the second terminal device.70.The second terminal device according to claim 69, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the second terminal device to perform the method according to any one of claims 16-23.71.A third terminal device (500) , comprising:one or more processors (501) ; andone or more memories (502) comprising computer program codes (503) ,the one or more memories (502) and the computer program codes (503) configured to, with the one or more processors (501) , cause the third terminal device (500) at least to:establish a common session between the third terminal device and a second network node, wherein the common session can be shared by different devices in a device group for user plane, UP, based communication between the different devices and the second network node via the third terminal device and a first network node, and the third terminal device is an intermediate device between the device group and the first network node.72.The third terminal device according to claim 71, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the third terminal device to perform the method according to any one of claims 25-32.73.A first network node (500) , comprising:one or more processors (501) ; andone or more memories (502) comprising computer program codes (503) ,the one or more memories (502) and the computer program codes (503) configured to, with the one or more processors (501) , cause the first network node (500) at least to:perform user plane, UP, based communication for data of a first terminal device via a common tunnel for a device group or a common session for the device group, wherein the UP based communication is between the first terminal device and a second network node via at least the first network node, and the first terminal device belongs to the device group.74.The first network node according to claim 73, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the first network node to perform the method according to any one of claims 34-54.75.A second network node (500) , comprising:one or more processors (501) ; andone or more memories (502) comprising computer program codes (503) ,the one or more memories (502) and the computer program codes (503) configured to, with the one or more processors (501) , cause the second network node (500) at least to:perform user plane, UP, based communication for data of a first terminal device via a common tunnel for a device group or a common session for the device group, wherein the UP based communication is between the first terminal device and the second network node via at least a first network node, and the first terminal device belongs to the device group.76.The second network node according to claim 75, wherein the one or more memories and the computer program codes are configured to, with the one or more processors, cause the second network node to perform the method according to any one of claims 56-66.77.A computer-readable medium having computer program codes (503) embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to any one of claims 1-66.

Images