WO2022228702A1

WO2022228702A1 - First node, second node, communications system and methods performed, thereby for handling tethering

Info

Publication number: WO2022228702A1
Application number: PCT/EP2021/064180
Authority: WO
Inventors: Miguel Angel MUÑOZ DE LA TORRE ALONSO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-04-28
Filing date: 2021-05-27
Publication date: 2022-11-03
Also published as: EP4331203A1

Abstract

A computer-implemented method, performed by a first node (111), for handling tethering. The first node (111) operates in the communications system (100). The first node (111) determines (309) whether or not one or more devices (130) operating in the communications system (100) are being tethered. The determining (306) is based on information gathered by the first node (111) from one or more second nodes (112) operating in the communications system (100). The information is indicative of tethered traffic in the communications system (100). The determining (306) is also based on a predictive model of tethering behavior. The first node (111) then initiates (310) providing a result of the determination to a third node (113) operating in the communications system (100).

Description

FIRST NODE, SECOND NODE, COMMUNICATIONS SYSTEM AND METHODS PERFORMED, THEREBY FOR HANDLING TETHERING

TECHNICAL FIELD

The present disclosure relates generally to a first node and methods performed thereby for handling tethering. The present disclosure also relates generally to a second node, and methods performed thereby for handling tethering. The present disclosure further relates generally to a communications system and methods performed thereby for handling tethering. The present disclosure also relates generally to computer programs and computer-readable storage mediums, having stored thereon the computer programs to carry out these methods.

BACKGROUND

Computer systems in a communications network may comprise one or more nodes. A node may comprise one or more processors which, together with computer program code may perform different functions and actions, a memory, a receiving port and a sending port. A node may be, for example, a server. Nodes may perform their functions entirely on the cloud.

The communications network may cover a geographical area which may be divided into cell areas, each cell area being served by another type of node, a network node in the RAN, radio network node or Transmission Point (TP), for example, an access node such as a Base Station (BS), e.g. a Radio Base Station (RBS), which sometimes may be referred to as e.g., evolved Node B (“eNB”), “eNodeB”, “NodeB”, “B node”, or Base Transceiver Station (BTS), depending on the technology and terminology used. The base stations may be of different classes such as e.g., Wide Area Base Stations, Medium Range Base Stations, Local Area Base Stations and Home Base Stations, based on transmission power and thereby also cell size. A cell is the geographical area where radio coverage is provided by the base station at a base station site. One base station, situated on the base station site, may serve one or several cells. Further, each base station may support one or several communication technologies. The telecommunications network may also be a non-cellular system, comprising network nodes which may serve receiving nodes, such as user equipments, with serving beams.

The standardization organization 3GPP is currently in the process of specifying a New Radio Interface called NR or 5G-UTRA, as well as a Fifth Generation (5G) Packet Core Network, which may be referred to as 5G Core Network, abbreviated as 5GC.

A 3GPP system comprising a 5G Access Network (AN), a 5G Core Network (5GC) and a UE may be referred to as a 5G system. Figure 1 is a schematic diagram depicting a particular example of a 5GC reference architecture as defined by 3GPP, which may be used as a reference for the present disclosure. A Network Data Analytics Function (NWDAF) 1 may be understood to represent an operator managed network analytics logical function. The NWDAF may be understood to be a part of the 5GC architecture and may use the mechanisms and interfaces specified for 5GC and Operation Administration and Maintenance (OAM). The NWDAF 1 may interact with different entities for different purposes. Data collection based on event subscription may be provided by an Access and Mobility Function (AMF) 2, a Session Management Function (SMF) 3, a Policy Control Function (PCF) 4, a Unified Data Management (UDM), an Application Function (AF) 5, directly or via a Network Exposure Function (NEF) 6, and an OAM. The NWDAF 1 may retrieve information from data repositories, e.g., a Unified Data Repository (UDR) 7 via the UDM for subscriber-related information. For retrieval of information about Network Functions (NFs), the NWDAF 1 may interact e.g., with a Network Repository Function (NRF) for Network Function (NF)-related information, and Network Slice Selection Function (NSSF) for slice-related information. The NWDAF 1 may also perform on demand provision of analytics to consumers.

The UDR 7 may store data grouped into distinct collections of subscription-related information, such as: subscription data, policy data, structured data for exposure, and/or application data.

The PCF 4 may be understood to support a unified policy framework to govern the network behavior. Specifically, the PCF may provide Policy and Charging Control (PCC) rules to a Policy and Charging Enforcement Function (PCEF), e.g., the SMF/User Plane Function (UPF) 6 that may enforce policy and charging decisions according to provisioned PCC rules.

A Charging Function (CHF) 8 may be understood to allow charging services to be offered to authorized NFs.

The SMF 3 may support different functionalities, e.g., the SMF 3 may receive PCC rules from the PCF and configure the UPF accordingly.

The User Plane function (UPF) 9 may support handling of user plane traffic based on the rules received from the SMF 3, e.g., packet inspection and different enforcement actions such as Guality of Service (CoS) handling.

Each of the UDR 7, the NEF 6, the NWDAF 1 , the AF 5, the PCF 4, the CHF 8, the AMF 2, the SMF 3 and the UPF 9 may have an interface through which they may be accessed, which as depicted in the Figure, may be, respectively: Nudr 10, Nnef 11, Nnwdaf 12, Naf 13, Npcf 14, Nchf 15, Namf 16, Nsmf 17 and N4 18.

Tethering Tethering may be understood as sharing an internet connection of a UE with one or more other gadgets. It is especially handy for subscribers getting their laptop or tablets online when they do not have an internet connection, e.g., 4G/5G, of their own.

The concept of Tethering may also be applied to other scenarios as well. For example, a 5G Residential Gateway (5G-RG) may be understood to be a special UE device, which may offer connectivity for in-home devices, fixed and mobile.

Machine Learning (ML)

ML may be understood as the study of computer algorithms that may improve automatically through experience. It may be considered as a part of artificial intelligence (Al). ML algorithms may build a model based on sample data, known as "training data", in order to make predictions or decisions without being explicitly programmed to do so. ML algorithms may be used in a wide variety of applications, such as email filtering and computer vision, where it may be difficult or unfeasible to develop conventional algorithms to perform the needed tasks.

There may be understood to be basically 3 types of ML algorithms: Supervised Learning, Unsupervised Learning and Reinforcement Learning.

The Supervised Learning algorithm may be understood to consists of a target and/or outcome variable, or dependent variable, which is to be predicted from a given set of predictors, that is, independent variables. Using this set of variables, a function may be generated that may map inputs to desired outputs. The training process may continue until the model achieves a desired level of accuracy on the training data. Examples of Supervised Learning may be: Regression, Decision Tree, Random Forest, K-Nearest Neighbors (KNN), Logistic Regression etc.

In the Unsupervised Learning algorithm, there may not be any target or outcome variable to predict and/or estimate. It may be used for clustering population in different groups, which may be widely used for segmenting customers in different groups for specific intervention. Examples of Unsupervised Learning may be: Apriori algorithm, and K-means.

Using the Reinforcement Learning algorithm, the machine may be trained to make specific decisions. It may be understood to works this way: the machine may be exposed to an environment where it may train itself continually using trial and error. This machine may learn from past experience and may try to capture the best possible knowledge to make accurate business decisions. Example of Reinforcement Learning may be the Markov Decision Process.

Network operators today may apply different traffic management actions, one of them being tethering detection and control, e.g., to block tethered traffic or to count the number of devices behind a tethered UE. It is very difficult for the network operator to detect tethering, as the traffic encryption is growing, and some advanced users may hack the UE to avoid tethering detection on the network side.

SUMMARY

It is an object of embodiments herein to improve the handling of tethering in a communications system.

According to a first aspect of embodiments herein, the object is achieved by a computer- implemented method, performed by a first node. The method is for handling tethering. The first node operates in a communications system. The first node determines whether or not one or more devices operating in the communications system are being tethered. The determining is based on information gathered by the first node from one or more second nodes operating in the communications system. The information is indicative of tethered traffic in the communications system. The determining is also based on a predictive model of tethering behavior. The first node also initiates providing a result of the determination to a third node operating in the communications system.

According to a second aspect of embodiments herein, the object is achieved by a computer-implemented method, performed by a second node of the one or more second nodes. The method is for handling the tethering. The second node operates in the communications system. The second node receives the indication from the first node operating in the communications system. The indication requests subscription to an event to receive information indicative of whether or not the one or more devices operating in the communications system are being tethered. The second node also sends, in response to the received indication, another indication. The another indication indicates the requested information.

According to a third aspect of embodiments herein, the object is achieved by a computer-implemented method, performed by a communications system. The communications system comprises the first node and the one or more second nodes. The method is for handling tethering. The method comprises receiving, by the one or more second nodes, the indication from the first node. The indication requests subscription to the event to receive information indicative of whether or not the one or more devices operating in the communications system are being tethered. The method also comprises sending, by the one or more second nodes, in response to the received indication, the another indication. The another indication indicates the requested information. The method additionally comprises determining, by the first node, whether or not the one or more devices are being tethered. The determining is based on the information gathered by the first node from the one or more second nodes. The information is indicative of tethered traffic in the communications system. The determining is also based on the predictive model of tethering behavior. The method further comprises initiating providing the result of the determination to the third node operating in the communications system.

According to a fourth aspect of embodiments herein, the object is achieved by the first node, for handling tethering. The first node is configured to operate in the communications system. The first node is further configured to determine whether or not one or more devices configured to operate in the communications system are being tethered. The determining is configured to be based on information configured to be gathered by the first node from the one or more second nodes configured to operate in the communications system. The information is configured to be indicative of tethered traffic in the communications system. The determining is configured to be based on the predictive model of tethering behavior. The first node is also configured to initiate providing the result of the determination to the third node configured to operate in the communications system.

According to a fifth aspect of embodiments herein, the object is achieved by the second node, for handling tethered. The second node is configured to operate in the communications system. The second node is further configured to receive the indication from the first node configured to operate in the communications system. The indication is configured to request subscription to the event to receive the information indicative of whether or not the one or more devices configured to operate in the communications system are being tethered. The second node is also configured to send, in response to the indication configured to be received, the another indication. The another indication is configured to indicate the information configured to be requested.

According to a sixth aspect of embodiments herein, the object is achieved by the communications system, for handling tethered. The communications system comprises the first node and the one or more second node. The communications system is configured to receive, by the one or more second nodes 112, the indication from the first node. The indication is configured to request subscription to is event to receive the information indicative of whether or not the one or more devices operating in the communications system are being tethered. The communications system is also configured to send, by the one or more second nodes, in response to the received indication, the another indication. The another indication is configured to indicate the information configured to be requested. The communications system is further configured to determine, by the first node, whether or not the one or more devices are being tethered. The determining is configured to be based on the information configured to be gathered by the first node from the one or more second nodes. The information is configured to be indicative of tethered traffic in the communications system. The determining is also configured to be based on the predictive model of tethering behavior. The communications system is also configured to initiate providing the result of the determination to a third node configured to operate in the communications system.

According to a seventh aspect of embodiments herein, the object is achieved by a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method performed by the first node.

According to an eighth aspect of embodiments herein, the object is achieved by a computer-readable storage medium, having stored thereon the computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method performed by the first node.

According to a ninth aspect of embodiments herein, the object is achieved by a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method performed by the second node.

According to a tenth aspect of embodiments herein, the object is achieved by a computer-readable storage medium, having stored thereon the computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method performed by the second node.

By the first device determining whether or not the one or more devices are being tethered based on the information gathered by the first node from the one or more second nodes, and the predictive model, the first node is enabled to more accurately determine whether tethering may be occurring or not. By then initiating providing the result of the determination, the first node may enable the third node to apply any corresponding actions based on the result provided. For example, the third node may decide to store in a subscriber profile an indication of a subscriber doing Tethering and the corresponding Tethering related information. Many different actions may be triggered by the third node based on the result, for example, improve a data service provided by an MNO by for example, if the tethered traffic represents a high percentage with respect to the total traffic volume, block the tethered traffic, block the traffic based on the number of tethering devices, notify a user, e.g., through SMS, e.g. if a subscriber is doing tethering from multiple devices, for example, over the maximum number of allowed tethering devices, change the Quality of Service (QoS), e.g., low QoS or Bandwidth (BW) limitation, and/or report it. If the confidence level of the result is medium, it may require further analysis, which may involve traffic steering, that is, to steer a copy of the tethered traffic towards an offline analytics engine. The third node may additionally or alternatively be enabled to store as subscriber data, for each identified device, an indication of being a subscriber and/or device where tethering has been detected and the corresponding tethering information, e.g., the percentage of tethered traffic or number of tethering devices. The information regarding tethering may then be used in subsequent sessions for the identified device, e.g., to continue monitoring Tethering for the identified device and, if the same behavior is found and/or if the accumulated Tethering volume exceeds a configured threshold, the user may be notified accordingly. By enabling the third node to obtain information about tethering behavior, the performance of the communications system may be enabled to be improved, as the result may enable the third node to manage the traffic in the communications system. For example, if the load of the communications system exceeds a certain threshold, the amount of traffic may need to be controlled to ensure a certain QoS for devices operating in certain areas, at a certain time, etc... so that the resources of the communications system may be optimally distributed.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to the accompanying drawings, according to the following description.

Figure 1 is a schematic diagram illustrating a non-limiting example of a 5G Network Architecture.

Figure 2 is a schematic diagram illustrating a non-limiting example of a communications system, according to embodiments herein.

Figure 3 is a flowchart depicting embodiments of a method in a first node, according to embodiments herein.

Figure 4 is a flowchart depicting embodiments of a method in a second node, according to embodiments herein.

Figure 5 is a flowchart depicting embodiments of a method in a communications system, according to embodiments herein.

Figure 6 is a schematic diagram depicting a first non-limiting example of signalling between nodes in a communications system, according to embodiments herein.

Figure 7 is a schematic diagram depicting a continuation of Figure 6.

Figure 8 is a schematic diagram depicting a second non-limiting example of signalling between nodes in a communications system, according to embodiments herein.

Figure 9 is a schematic diagram depicting a continuation of Figure 8.

Figure 10 is a schematic diagram depicting a continuation of Figure 9.

Figure 11 is a schematic diagram depicting a third non-limiting example of signalling between nodes in a communications system, according to embodiments herein.

Figure 12 is a schematic diagram depicting a continuation of Figure 11.

Figure 13 is a schematic diagram depicting a continuation of Figure 12. Figure 14 is a schematic block diagram illustrating two non-limiting examples, a) and b), of a first node, according to embodiments herein.

Figure 15 is a schematic block diagram illustrating two non-limiting examples, a) and b), of a second node, according to embodiments herein.

Figure 16 is a schematic block diagram illustrating two non-limiting examples, a) and b), of a communications system, according to embodiments herein.

DETAILED DESCRIPTION

Embodiments herein may be understood to relate to a mechanism which addresses the above problems, and which may be understood to be based on the definition of a new type of analytic relative to tethering. This new type of analytic may allow a mobile network operator (MNO) to detect tethering and to act upon it.

One of the main objectives of an MNO may be understood to be to control all the traffic traversing network of an MNO. Embodiments herein may be understood to specifically propose a mechanism to perform statistics and analytics on tethering behavior, e.g., so as to improve the network performance of a MNO.

Particular embodiments herein may be understood to relate to tethering detection based on analytics in 5G networks.

The embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which examples are shown. In this section, embodiments herein are illustrated by exemplary embodiments. It should be noted that these embodiments are not mutually exclusive. Components from one embodiment or example may be tacitly assumed to be present in another embodiment or example and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. All possible combinations are not described to simplify the description.

Figure 2 depicts two non-limiting examples, in panels “a” and “b”, respectively, of a communications system 100, in which embodiments herein may be implemented. In some example implementations, such as that depicted in the non-limiting example of Figure 2a, the communications system 100 may be a computer network. In other example implementations, such as that depicted in the non-limiting example of Figure 2b, the communications system 100 may be implemented in a telecommunications system, sometimes also referred to as a telecommunications network, cellular radio system, cellular network or wireless communications system. In some examples, the telecommunications system may comprise network nodes which may serve receiving nodes, such as wireless devices, with serving beams. In some examples, the telecommunications system may for example be a network such as 5G system, or a newer system supporting similar functionality. The telecommunications system may also support other technologies, such as a Long-Term Evolution (LTE) network, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half- Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band,

Wideband Code Division Multiple Access (WCDMA), Universal Terrestrial Radio Access (UTRA) TDD, Global System for Mobile communications (GSM) network, GSM/Enhanced Data Rate for GSM Evolution (EDGE) Radio Access Network (GERAN) network, Ultra-Mobile Broadband (UMB), EDGE network, network comprising of any combination of Radio Access Technologies (RATs) such as e.g. Multi-Standard Radio (MSR) base stations, multi-RAT base stations etc., any 3rd Generation Partnership Project (3GPP) cellular network, Wreless Local Area Network/s (WLAN) or WFi network/s, Worldwide Interoperability for Microwave Access (WiMax), IEEE 802.15.4-based low-power short-range networks such as IPv6 over Low-Power Wreless Personal Area Networks (6LowPAN), Zigbee, Z-Wave, Bluetooth Low Energy (BLE), or any cellular network or system. The telecommunications system may for example support a Low Power Wide Area Network (LPWAN). LPWAN technologies may comprise Long Range physical layer protocol (LoRa), Haystack, SigFox, LTE-M, and Narrow-Band loT (NB-loT).

Although terminology from Long Term Evolution (LTE)/5G has been used in this disclosure to exemplify the embodiments herein, this should not be seen as limiting the scope of the embodiments herein to only the aforementioned system. Other wireless systems support similar or equivalent functionality may also benefit from exploiting the ideas covered within this disclosure. In future telecommunication networks, e.g., in the sixth generation (6G), the terms used herein may need to be reinterpreted in view of possible terminology changes in future technologies.

The communications system 100 may comprise a plurality of nodes, and/or operate in communication with other nodes. In Figure 2, panel a) depicts a first node 111, one or more second nodes 112, and a third node 113. The one or more second nodes 112 may comprise a first second node 114, a second second node 115 and a third third node. The third third node may be the first device 131, which will be described later. Any of the first node 111, the one or more second nodes 112, the third node 113, the first second node 114 and the second second node 115 may be understood, respectively, as a first computer system, one or more second computer systems, a third computer system, a fourth computer system and a fifth computer system. In some examples, any of the first node 111 , the one or more second nodes 112, the third node 113, the first second node 114 and the second second node 115 may be implemented as a standalone server in e.g., a host computer in the cloud 120, as depicted in the non-limiting example depicted in panel b) of Figure 2. Any of the first node 111 , the one or more second nodes 112, the third node 113, the first second node 114 and the second second node 115 may in some examples be a distributed node or distributed server, with some of their respective functions being implemented locally, e.g., by a client manager, and some of its functions implemented in the cloud 120, by e.g., a server manager. Yet in other examples, any of the first node 111 , the one or more second nodes 112, the third node 113, the first second node 114 and the second second node 115 may also be implemented as processing resources in a server farm.

In some embodiments, any of the first node 111 , the one or more second nodes 112, the first second node 114 and the second second node 115 may be co-located or be the same node. Particularly, the first node 111 may either be a central node or may be co-located with the second second node 115.

All the possible combinations are not depicted in Figure 2 to simplify the Figure.

It may be understood that the communications system 100 may comprise more nodes than those represented on panel a) of Figure 2. In some examples, such as that depicted on panel b) of Figure 2, the communications system 100 may comprise a fourth node 116 and/or another node 117. Any of the fourth node 116 and the another node 117 may be understood to have a description equivalent to that provided above for the first node 111 , the one or more second nodes 112 or the third node 113.

The fourth node 116 may be understood to have a capability to allow external parties to use the Exposure Application Program Interfaces (APIs) offered by the network operator of the communications system 100, such as an AF in 5G, a Service Capability Server/Application Server (SCS/AS) in 4G,or a node or database capable of performing a similar function in the communications system 100.

In some examples of embodiments herein, the first node 111 may be a node having a capability to retrieve information from data repositories, such as the first second node 114, e.g., a Unified Data Repository (UDR), for subscriber-related information, retrieve information about NFs, and perform on demand provision of analytics to consumers. In particular non limiting examples, the first node 111 may be an NWDAF.

The first second node 114 may be a node having a capability to store data grouped into distinct collections of subscription-related information, such as: subscription data, policy data, structured data for exposure, and/or application data. In particular non-limiting examples, the first node 111 may be a UDR.

The second second node 115 may be a node having a capability to support handling of user plane traffic based on rules received from another node, e.g., an SMF, on for example, packet inspection and different enforcement actions such as QoS handling. In particular non limiting examples, the first node 111 may be a UPF. The third node 113 may be understood to as a node consuming the analytics performed by the first node 111. In particular non-limiting examples, the third node 113 may be a PCF or an OAM.

Particularly, the another node 117 may be understood as a node having a capability to train a machine-learning model.

The communications system 100 may comprise one or more first devices 130, which are referred to herein simply as one or more devices 130, and which may comprise at least a first device 131. Three one or more devices 130 are depicted in panel b) of Figure 2. However, it may be understood that fewer or more than three devices may be comprised in the one or more devices 130. The communications system 100 may also comprise one or more second devices 140, which may comprise at least a second device 141. Only the second device 141 is depicted in Figure 2. However, it may be understood that more than one device may be comprised in the one or more second devices 140. The one or more of devices 130 may be understood to be tethered by the one or more second devices 140. Any of the one or more devices 130 and the one or more second devices 140 may be also known as e.g., user equipment (UE), a wireless device, mobile terminal, wireless terminal and/or mobile station, mobile telephone, cellular telephone, or laptop with wireless capability, or a Customer Premises Equipment (CPE), just to mention some further examples. Any of the one or more devices 130 in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or a vehicle-mounted mobile device, enabled to communicate voice and/or data, via a RAN, with another entity, such as a server, a laptop, a Personal Digital Assistant (PDA), or a tablet computer, sometimes referred to as a tablet with wireless capability, or simply tablet, a Machine-to-Machine (M2M) device, a device equipped with a wireless interface, such as a printer or a file storage device, modem, Laptop Embedded Equipped (LEE), Laptop Mounted Equipment (LME), USB dongles, CPE or any other radio network unit capable of communicating over a radio link in the communications system 100. Any of the one or more devices 130 and the one or more second devices 140 may be wireless, i.e. , it may be enabled to communicate wirelessly in the communications system 100 and, in some particular examples, may be able support beamforming transmission. The communication may be performed e.g., between two devices, between a device and a radio network node, and/or between a device and a server. The communication may be performed e.g., via a RAN and possibly one or more core networks, comprised, respectively, within the communications system 100. In some particular embodiments, any of the one or more devices 130 and the one or more second devices 140 may be an Internet of Things (loT) device, e.g., a NB loT device. The communications system 100 may comprise one or more radio network nodes, whereof a radio network node 150 is depicted in Figure 2b. The radio network node 150 may typically be a base station or Transmission Point (TP), or any other network unit capable to serve a wireless device or a machine type node in the communications system 100. The radio network node 150 may be e.g., a 5G gNB, a 4G eNB, or a radio network node in an alternative 5G radio access technology, e.g., fixed or WiFi. The radio network node 150 may be e.g., a Wde Area Base Station, Medium Range Base Station, Local Area Base Station and Home Base Station, based on transmission power and thereby also coverage size. The radio network node 150 may be a stationary relay node or a mobile relay node. The radio network node 150 may support one or several communication technologies, and its name may depend on the technology and terminology used. The radio network node 150 may be directly connected to one or more networks and/or one or more core networks.

The communications system 100 covers a geographical area which may be divided into cell areas, wherein each cell area may be served by a radio network node, although, one radio network node may serve one or several cells.

The first node 111 may communicate with each of the one or more second nodes over a respective link, e.g., a radio link or a wired link. For example, the first node 111 may communicate with the first second node 114 over a first link 151, e.g., a radio link or a wired link. The first node 111 may communicate with the second second node 115 over a second link 152, e.g., a radio link or a wired link. The first node 111 may communicate with the third node 113 over a third link 153, e.g., a radio link or a wired link. The first second node 114 may communicate with the second second node 115 over a fourth link 154, e.g., a radio link or a wired link. The second second node 115 may communicate, directly or indirectly, with any of the one or more devices 130 over a respective fifth link 155, e.g., a radio link or a wired link. The first device 131 may communicate with the second device 141 over a sixth link 156, e.g., a radio link. It may be understood that each of the one or more second devices 112 may communicate with its respective one or more second devices 140 over a respective sixth link. The radio network node 150 may communicate directly or indirectly, with any of the one or more devices 130 over a respective over a seventh link 157, e.g., a radio link or a wired link. The second second node 115 may communicate, directly or indirectly with the radio network node 150 over an eighth link 156, e.g., a radio link or a wired link. Any of the first link 151, the second link 152, the third link 153, the fourth link 154, the fifth link 155, the seventh link 157 and/or the eighth link 158 may be a direct link or it may go via one or more computer systems or one or more core networks in the communications system 100, or it may go via an optional intermediate network. The intermediate network may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network, if any, may be a backbone network or the Internet, which is not shown in Figure 2.

In general, the usage of “first”, “second”, “third”, “fourth”, “fifth”, “sixth”, “seventh” and/or “eighth” herein may be understood to be an arbitrary way to denote different elements or entities, and may be understood to not confer a cumulative or chronological character to the nouns these adjectives modify.

Embodiments of a computer-implemented method, performed by the first node 111 , will now be described with reference to the flowchart depicted in Figure 3. The method may be understood to be for handling tethering. The first node 111 operates in the communications system 100.

The method may comprise the actions described below. In some embodiments all the actions may be performed. In some embodiments some of the actions may be performed. In Figure 3, optional actions are indicated with a dashed box. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example or embodiment may be tacitly assumed to be present in another example or embodiment and it will be obvious to a person skilled in the art how those components may be used in the other examples or embodiments.

In Figure 3, optional actions are represented with dashed boxes.

Action 301

Embodiments herein may be understood to relate to a new type of analytic relative to tethering, which may allow a network operator to detect tethering and to act upon it. According to embodiments herein, the third node 113, which may be managed by the operator of the network, may request the first node 111 to provide such an analytic. Accordingly, in this Action 301 , the first node 111 may receive a first indication from the third node 113. The first indication may request to receive one or more analytics on whether or not the one or more of devices 130 are being tethered. The first indication may indicate: i) one or more applications, that is, the one or more applications for which the one or more analytics may want to be received; and ii) one or more identifiers of one or more devices 130, that is the one or more devices 130 for which the one or more analytics may want to be received. The one or more applications that may be indicated may be understood to be the target for tethering. They may be indicated as a single App-I D or as a list of App-I D, indicating the App-I D/s one of the one or more applications. As an example, the third node 113 may be interested in one or more tethering analytics related to video streaming applications. For example, the third node 113 may want to know the percentage of subscribers running video streaming through tethered devices. In case the one or more applications are not indicated explicitly, e.g., no identifier of the one or more applications such as App-ID is included in the first indication as may be the case, for example, if the list is empty, the first node 111 may interpret that all user traffic may be subject to this analytic.

The one or more identifiers of the one or more devices 130 may be indicated as an individual UE-ID, as a list of UE-ID, UE-Group-ID or list of UE-Group-ID, or as AnyUE. This may be understood to indicate that the UE/s which may be the target for the one or more tethering analytics. When the one or more identifiers are not present, AnyUE may be understood to apply.

The first indication may be understood as a subscription to the first node 111 from the third node 113 to receive information related to the new analytic, which may be identified as e.g., Analytic-ID= Tethering. That is, the first indication may comprise the parameter Analytic- ID= Tethering.

In some embodiments, the first node 111 may be an NWDAF. In some of such embodiments, the third node 113 may be a consumer, such as any NF, e.g., a PCF or an OAM. The first indication may be in some examples a

Nnwdaf_AnalyticsSubscription_Subscribe request message. The first indication may comprise the identifier of the one or more analytics requested, e.g., in the form of the parameter Analytic-I D=T ethering.

The receiving in this Action 301 may be performed via the third link 153.

The first node 111 may answer to the third node 113 with a successful response accepting the request.

By receiving the first indication in this Action 301 , the first node 111 may be enabled to trigger a gathering of information indicative of whether or not the one or more of devices 130 are being tethered from the one or more second nodes 112 in Action 302, Action 303 and Action 304, which information may ultimately enable the first node 111 to determine whether or not the one or more devices 130 are being tethered.

Action 302

In some embodiments, the first node 111, in this Action 302, may send a second indication to the first second node 114 of the one or more second nodes 112. The second indication may request subscription to receive first information of the information indicative of whether or not the one or more of devices 130 are being tethered.

The first information may indicate historic tethering information of the one or more devices 130. That is, the first information may indicate statistical information of past events. In order to do this, the first node 111 may request the subscriber data relative to the indicated one or more devices 130 from the first second node 114. The first information may indicate at least the one or more identifiers of the one or more devices 130, such as for example, UE-ID as parameter, and optionally also including the list of App-ID.

The second indication may additionally indicate the one or more applications as indicated by the third node 113. Additionally, the first node 111 may indicate that it may wish to retrieve the subscriber identifier, e.g., Subscription Permanent Identifier (SUPI)/

International Mobile Subscriber Identifier (IMSI), the subscriber public identifier Public User Identity (PUI)/ Mobile Station Integrated Services Digital Network (MSISDN) and/or device identifier Permanent Equipment Identity (PEI)/ International Mobile Equipment Identifier (IMEI) for any relevant session of the one or more devices 130, as indicated by their respective UE- ID session.

In some embodiments, the first node 111 may be the NWDAF and the first second node 114 may be the UDR. In examples of such embodiments, the second indication may be, for example, a Nudr_Query request message indicating UE-ID as parameter, and optionally also including the list of App-ID.

The sending in this Action 302 may be performed e.g., via the first link 151.

In some embodiments, the sending in this Action 302 of the second indication may be triggered by the receiving in Action 301 of the first indication.

By sending the second indication, the first node 111 may trigger data collection from the first second node 114 which data may ultimately enable the first node 111 to determine whether or not the one or more devices 130 are being tethered, based on historic information.

Action 303

In some embodiments, the first node 111, in this Action 303, may send a third indication to the second second node 115 of the one or more second nodes 112. The third indication may request subscription to a first event. The first event may be to receive second information, of the information indicative of whether or not the one or more of devices 130 are being tethered. The second information may comprise information relative to protocol metrics for the one or more of devices 130. Alternatively, data collection from the second second node 115 may be regarding mirrored data, that is, raw packets, as will be described later with an illustrative example.

The second information may indicate at least one of: i) a first identifier of the requested first event, which may be, for example, a parameter Event-ID=ProtocolMetrics, ii) protocol metrics; iii) the one or more applications, that is, the one or more applications for which protocol metrics may be required, such as for example, the list of App-ID; and iv) the one or more identifiers of the one or more devices 130, that is, the target devices for this event, as indicated, for example, by UE-ID as parameter. Optionally, the third indication may comprise a marking for tethering traffic. This marking may be e.g., a parameter, Tag-ID, which may indicate that tethering traffic is marked with Tag-ID. It may be optional as it may also be possible that the Tag-ID value may be preconfigured, specifically, by the first device 131, i.e., the tethering UE, to mark the traffic with Tag-ID, and/or by the second second node 115, to detect tethering traffic which may be marked with Tag-ID.

The protocol metrics may be understood to be data relative to a certain protocol, e.g., TCP, where the data may refer either directly to the value of certain fields for that protocol, e.g., time to live value in the protocol header, or to processed data such as the average or variance of certain parameters obtained from multiple packets for that protocol. For example, protocol metrics may be a Protocol-Metrics. The Protocol-Metrics parameter may comprise, a set of values and flags for Transmission Control Protocol (TCP) signalling packets, and also other non-transport related parameters such as Hypertext Transport Protocol (HTTP) User- Agent, specifically: Internet Protocol (IP) Packet length, Initial Time to Live (TTL) value, TCP window length, TCP window size scale, TCP Maximum Segment Size (MSS), TCP Option Selective ACK, TCP Option Timestamp, TCP Option End of Options (EOL), TCP Option NO Operation (NOP) count, HTTP User-Agent, etc.

The second information may further indicate, for each detected flow, a timestamp indicating the start and stop time for the flow, a 5-tuple, a volume, an identifier of the protocol used, e.g., via a Protocol-ID parameter such as TCP, User Datagram Protocol (UDP), Guick UDP Internet Connections (GUIC), etc.

In some embodiments, the first node 111 may be the NWDAF and the second second node 115 may be the UPF. In examples of such embodiments, the second indication may be, for example, a Nupf_EventExposure_Subscribe request message. The Nupf_EventExposure_Subscribe request message may include the following parameters: Event-ID=ProtocolMetrics, and, optionally, the list of App-ID, and the UE-ID.

For embodiments wherein the first node 111 may be the NWDAF and the second second node 115 may be the UPF, it may be understood that it is not in scope of this disclosure to describe the specific mechanism by which the NWDAF may trigger data collection from the UPF. As a non-limiting example, the existing mechanisms proposed in 3GPP TR 23.700-91 , v. 17.0.0, may be used, e.g., through an SMF or directly, assuming a service based UPF.

The sending in this Action 303 may be performed e.g., via the second link 152.

In some embodiments, the sending in this Action 303 of the third indication may be triggered by the receiving in Action 301 of the first indication.

In some examples, the first node 111 may, in this Action 303 trigger data collection from the second second node 115 relative to mirrored data. In such embodiments, the first node 111 may trigger data collection from the second second node 115, specifically to retrieve mirrored data, that is, raw IP packets, for the indicated UE-ID. In order to do this, the first node 111 may, in this Action 303, trigger the second indication, e.g., as a Nupf_EventExposure_Subscribe request message including the following parameters. The first identifier of the requested first event may in these embodiments be Event-ID=Mirroring. Optionally, the one or more identifiers of the one or more devices 130 as e.g., the list of App- ID, which indicates the App-ID/s for which mirrored data may be required, and UE-ID, which may indicate the target UE/s for this event.

The second second node 115 may answer to the first node 111 with a successful response accepting the request.

By sending the third indication, the first node 111 may trigger data collection from the second second node 112, specifically to retrieve information relative to protocol metrics for the one or more of devices 130, which data may ultimately enable the first node 111 to determine whether or not the one or more devices 130 are being tethered.

Action 304

In some embodiments, the first node 111, in this Action 304, may send a fourth indication to the third second node. The third second node may be the first device 131 of the one or more devices 130. The fourth indication may request subscription to a second event. The second event may be to receive third information indicative of whether or not the first device 131 is being tethered. The third information may comprise information to active (OS) applications for the first device 131.

The third information may indicate at least one of: i) a second identifier of the requested second event, which may be, for example, a parameter Event-ID=OSApplications, ii) the one or more applications, that is, the one or more applications which this event may apply to, such as for example, the list of App-ID; and iv) an identifier of the first device 131, that is, the target device for this event, as indicated, for example, by UE-ID as parameter.

In some embodiments, the first node 111 may be the NWDAF and the first device 131 may be a UE. In examples of such embodiments, the fourth indication may be, for example, a Nue_EventExposure_Subscribe request message. The Nue_EventExposure_Subscribe request message may include the following parameters: Event-ID=OSApplications, and, optionally, the list of App-ID, and the UE-ID.

For embodiments wherein the first node 111 may be the NWDAF, it may be understood that it is not in scope of this disclosure to describe the specific mechanism by which the NWDAF may trigger data collection from the UE. As a non-limiting example, the existing mechanisms proposed in 3GPP TR 23.700-91, v. 17.0.0, may be used.

The sending in this Action 304 may be performed e.g., via the second link 152 and the fifth link 155.

In some embodiments, the sending in this Action 304 of the fourth indication may be triggered by the receiving in Action 301 of the first indication. In some embodiments, the sending 302, 303, 304 of at least one of the second indication, the third indication and the fourth indication may triggered by the receiving 301 of the first indication.

The first device 131 may answer to the first node 111 with a successful response accepting the request.

By sending the fourth indication, the first node 111 may trigger data collection from the third second node, specifically to retrieve to active (OS) applications for the first device 131 , which data may ultimately enable the first node 111 to determine whether or not the first device 131 is being tethered.

Action 305

In this Action 305, the first node 111 may receive, in response to the sent second indication, a fifth indication from the first second node 114. The fifth indication may indicate the requested first information. For example, the first second node 114, a UDR, may return the subscriber data and/or application data for the indicated one or more devices 130, e.g., for a UE-ID, including historic tethering related information for the indicated UE-ID.

The receiving in this Action 305 may be performed e.g., via the first link 151.

By the first node 111 receiving the fifth indication, the first node 111 may then be enabled to later, in Action 309, determine whether or not the first device 131 is being tethered.

Action 306

After having received the fourth indication, and during the course of operations in the communications system 100, a user may start an application, e.g., example.com, from the first device 131, which may be considered the main UE of the user. The first device 131 may be understood to be the Tethered UE. The first device 131, after receiving the fourth indication, may have gathered data for the second event, e.g., Event-ID=OSApplications. In particular, the first device 131 may store the third information. When the one or more applications are indicated in the fourth indication from the first node 111, e.g., as the list of App-ID, the first device 131 may filter the third information based on that list. The third information may comprise: the identifiers of the one or more applications, such as the paramter OSApplication- ID, e.g., example.com, for each flow: the timestamp indicating the start time for the flow, the 5- tuple, and the volume.

The first device 131 may continue gathering data for the second event, e.g., Event- ID=OSApplications, both when it may be itself that may initiate the application traffic, or when it may be the second device 132, that may initiate it by tethering to the first device 131. At some point, e.g., in the case of periodic reporting, the first device 131 may report data for the second event, e.g., Event-ID= OSApplications. In order to do that, the first device 131 may notify the first node 111.

According to the foregoing, in this Action 306, the first node 111 may receive, in response to the sent fourth indication, a sixth indication from the third second node, that is, from the first device 131. The sixth indication may indicate the requested third information.

The sixth indication may be, for example, in embodiments wherein the first node 111 may be a NWDAF, a Nue_EventExposure_Notify request message.

The third information received from the first device 131 may be that which the first device 131 may have stored, as indicated above. For example, the third information comprised in the sixth indication may comprise the following parameters: the second identifier of the requested second event, e.g., Event-ID= OSApplications, the identifier of the first device 131, e.g., UE- ID, and information regarding the one or more applications, for example via the parameter OSApplicationslnfo. This parameter may include the following information, which may have been stored in previous steps: OSApplication-ID, e.g., example.com, and for each flow: the timestamp indicating the start time for the flow, the 5-tuple, and the volume, which may optionally differentiate uplink and downlink volume.

The receiving in this Action 306 may be performed e.g., via the second link 152 and the fifth link 155.

The first node 111 may answer to the receipt of the sixth indication may sending a message indicating successful operation.

By the first node 111 receiving the sixth indication, the first node 111 may then be enabled to later, in Action 309, determine whether or not the first device 131 is being tethered.

Action 307

During the course of operations in the communications system 100, the user of the first device 131 may send application traffic, e.g., example.com towards the second second node 115. The second second node 115 may have detected the application traffic, e.g., example.com, and gathered data for the first event identified by the first node 111, e.g., Event- ID=ProtocolMetrics. The second second node 115 may have stored the second information, which may comprise following information: the one or more applications, e.g., App-ID such as example.com, and for each detected flow: the timestamp indicating the start and stop time for the flow, the 5-tuple, the volume, the Protocol-ID, e.g., TCP, UDP, QUIC, etc, the Protocol- Metrics, including the set of values and flags for TCP signaling packets, and also other non transport related parameters like HTTP User-Agent. The other non-transport related parameters may specifically comprise IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc...

In some embodiments, such as those wherein the first node 111 may perform Action 308 described later, the second second node 115 may additionally store for each detected flow: an indication of whether the flow may be tethering or no-tethering, e.g.: tagged, with for example Tag-ID, or not. Tagged, with Tag-ID, may be understood to mean that it is a tethered flow, and non-tagged may be understood to mean it is a non-tethered flow.

At some point, the user may start an application, e.g., example.com, from the second device 141, that is a secondary UE, which may be understood to be the Tethering UE. The user of the first device 131 may also send this application traffic, e.g., example.com towards the second second node 115. The second second node 115 may have detected this other application traffic, e.g., example.com, and gathered second information for the first event identified by the first node 111, e.g., Event-ID=ProtocolMetrics. The second second node 115 may have also stored the identifier of the one or more applications that may apply, e.g. by storing the parameter App-ID, such as example.com.

The second second node 115 may have stored and may optionally remove the mark Tag-ID before forwarding the traffic towards an application server providing content: App-ID, here example.com, and for each detected flow: an indication of whether the flow is tethering or no-tethering. For example: Tagged, with Tag-ID, or not. Tagged, with Tag-ID, may be understood to mean it is a tethered flow and non-tagged may be understood to mean it is a non-tethered flow.

The second second node 115 may have continued gathering second information for the first event, e.g., Event-ID=ProtocolMetrics and at some point, in the case of e.g., periodic reporting, the second second node 115 may report the collected second information data for the first event of the second node 111.

In this Action 307, the first node 111 may receive, in response to the sent third indication, a seventh indication from the second second node 115. The seventh indication may indicate the requested second information. In embodiments wherein the first node 111 may be a NWDAF, the seventh indication may be a Nupf_EventExposure_Notify request message.

The seventh indication may include the following parameters: the first identifier of the first event, e.g., Event-ID=ProtocolMetrics, the one or more identifiers of the one or more devices 130, e.g., UE-ID, the protocol metrics, e.g., via the parameter ProtocolMetricslnfo.

This parameter may include the following information: the identifier of the one or more applications, e.g., App-ID, such as example.com, and for each detected flow: the timestamp indicating the start and stop time for the flow, the 5-tuple, the volume, the Protocol-ID, such as TCP, UDP, QUIC, etc., the parameter Protocol-Metrics, including the set of values and flags for TCP signaling packets, and also other non-transport related parameters such as HTTP User-Agent. For example, if the application example.com uses TCP as transport protocol, the following TCP protocol metrics may be included: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc.

The receiving in this Action 307 may be performed e.g., via the second link 152.

In some embodiments, wherein the first node 111 may have subscribed to the receive mirrored information, the second second node 115 may have detected application traffic, generated a duplicate for each packet and stored it for Event-ID=Mirroring. The second second node 115 may have stored the following information: App-ID, here example.com, and for each detected flow: Timestamp, indicating the start and stop time for the flow, and raw IP packets for the whole flow. After the second second node 115 may detect application traffic, it may generate a duplicate for each packet and store it for Event-ID=Mirroring. The second second node 115 stores the following information: App-ID, here example.com, and for each detected flow: Timestamp, indicating the start and stop time for the flow, and Raw IP packets for the whole flow. The first node 111 may then obtain this second information in the seventh indication in this Action 307.

The first node 111 may answer to the receipt of the seventh indication may sending a message indicating successful operation.

By the first node 111 receiving the seventh indication, the first node 111 may then be enabled to later, in Action 309, determine whether or not the first device 131 is being tethered.

Action 308

In some examples, the first node 111 may have the capability to train a machine-learning model. In this Action 308, the first node 111 may train a machine-learning (ML) model based on at least a first subset of one or more of: the first information, the second information, and the third information. The first subset may be understood to refer to the fact that not all the information gathered may be used to train the ML model, since the ML model may be trained during an earlier point of time, and the gathering of information may continue, in parallel and/or at a later point in time.

The training may be performed with, for example, through supervised ML algorithms such as decision tree, random forest, regression, etc.

The information collected may be tagged and untagged by the one or more second devices 140, e.g., the second device 141, where tagged may be understood to correspond to information collected from tethered traffic, and untagged may be understood to correspond to information collected from non-tethered traffic. The tag may be e.g., a Tag-ID, such as e.g., Differentiated Services Code Point (DSCP) marking, an IP Options header, etc.

The training in this Action 308 may comprise a) collecting a first set and a second set of any of the first information, the second information, and the third information, as received, respectively, from the first second node 114, the second second node 115 and the first device 131 , said first set corresponding to traffic for the second device 141 , that is, the tethering device, tagged as tethered traffic, and a second set corresponding to traffic for the first device 131, that is, the tethered device, tagged as tethered traffic, b) optionally, applying one or more transformations to each of the first information, the second information, and the third information in the first set and in the second set, if necessary, c) creating a first training set comprising the collected first set, or the transformed first set, and the second set or the transformed second set, c) training the machine-learning model in a first stage using the first training set; d) creating a second training set for a second stage of training comprising the first training set and traffic from the second set that is incorrectly detected as tethering traffic after the first stage of training; and e) training the machine-learning model in a second stage using the second training set.

Action 309

In this Action 309, the first node 111, determines whether or not the one or more devices 130 operating in the communications system 100 are being tethered. The determining in this action 306 may be based on: i) the information gathered by the first node 111 from the one or more second nodes 112 operating in the communications system 100, the information being indicative of tethered traffic in the communications system 100, and ii) a predictive model of tethering behavior.

Determining may be understood as e.g., calculating, deciding or detecting.

The predictive model may be the ML model trained in Action 308. That is, the determining in this Action 309 of whether or not the one or more of devices 130 are being tethered may be based on the trained ML model in Action 308. In other words, to detect Tethering, the first node 111 may uses the ML model trained in Action 308, obtained through the training process described in Action 308. Alternatively, the predictive model may be a trained ML model available at the first node 111.

Additionally, in this Action 309, the first node 111 may search for unexpected or uncorrelated data that may be indicative of Tethering. As an example, the first node 111 may run the following logic.

The determining in this Action 309 of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be based on the received seventh indication. By analyzing both the one or more identifiers of the one or more devices 130, e.g., the PEI/IMEI, specifically the Type Allocation Code (TAC) to identify smart vs. non-smart devices, and the protocol metrics, e.g., TCP related parameters, reported by the second second node 115, the first node 111 may detect tethering, on a per application basis, though, for example OS fingerprinting techniques.

In some embodiments, the determining in this Action 309 of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be based on the received fifth indication. In some embodiments, the determining in this Action 309 of whether or not the one or more of devices 130 are being tethered may be based on the received sixth indication. In case of data collection both from the first device 131 and the first second node 114, the first node 111 may also correlate the first second node 114 and the first device 131 events, e.g., by analyzing both timestamps and volume, if the OSApplication-IDs reported from the first device 131 do not match with the App-IDs detected by the second second node 115, the first node 111 may determine tethering for the App-ID.

By performing the determining in this Action 309, the first node 111 may be understood to run analytic processes and produce one or more analytics based on the data collected from the first second node 114, the second second node 115 and the first device 131.

Based on the above, the first node 111 may determine that Tethering is happening and may store the following information, on a per UE-ID basis. According to a first option, the first node 111 may store a subset of the one or more applications, e.g., as a List of App-IDs, which may identify the App-IDs from which tethering has been run. According to a second option, the first node 111 may store a number of tethered devices as a Number of tethered devices parameter, which may identify the number of tethered devices. According to a third option, the first node 111 may store a tethering volume as e.g., a Tethering volume parameter. This parameter may include the percentage with respect to the total traffic volume.

The first node 111 may then produce as a result, an AnalyticResult parameter. The AnalyticResult parameter may include an identifier of the analytic provided as the Analytic-ID= Tethering. The AnalyticResult parameter may include the following information, stored as described above: which of the one or more devices 130 may been found to use tethering, as the parameter List of UE-IDs. Each UE-ID may include the subscriber identifier, e.g., SUPI/IMSI, the subscriber public identifier, e.g., PUI/MSISDN, and/or device identifier, e.g., PEI/IMEI. The AnalyticResult parameter may include additionally or alternatively the subset of the one or more applications, e.g., as a List of App-IDs, which may identify the App-IDs from which tethering has been run, the number of tethered devices as a Number of tethered devices parameter, which may identify the number of tethered devices. In case the analytic may be for AnyUE, the message may include the average number of tethered devices. The AnalyticResult parameter, may include the tethering volume as e.g., the Tethering volume parameter. This parameter may include the percentage with respect to the total traffic volume. This may be used e.g., to determine how much traffic may be tethered on a per global basis, on a per UE-ID basis and/or on a per application basis.

Action 310

In this Action 310, the first node 111, initiates providing the result of the determination performed in Action 309 to the third node 113 operating in the communications system 100.

Initiating may be understood as triggering, enabling, starting or similar. That the first node 111 initiates providing may be understood to mean that the first node 111 may perform an action which may ultimately lead to the sending of the result to the third node 113.

The providing may be performed by sending a message e.g., via the third link 153.

Based on the above, in this Action 310, the first node 111 may notify the third node 113 by triggering a Nnwdaf_AnalyticsSubscription_Notify request message including the following parameters: the identifier of the analytic as the parameter Analytic-ID=Tethering, the one or more identifiers of the one or more devices 130 which may have been found to use tethering as a List of UE-IDs. Each identifier may include the subscriber identifier, e.g., SUPI and/or IMSI, the subscriber public identifier, e.g., PUI/MSISDN, and/or device identifier, e.g.,

PEI/IMEI.

The message comprising the result may, for example, comprise the AnalyticResult parameter described above.

In some embodiments wherein the first node 111 may be a NWDAF, the third node 113 may be one of a PCF or an OAM, and the one or more second nodes 112 may be at least one of: a UPF and a UDR.

In some examples, the first node 111 may output the result internally.

By initiating providing the result of the determination in this Action 310, the first node 111 may enable the third node 113 to apply any corresponding actions based on the result provided, e.g., the AnalyticResult. For example, the third node 113 may decide to store in the subscriber profile an indication of a subscriber doing Tethering and the corresponding Tethering related information. Many different actions may be triggered by the third node 113 based on the result, for example, improve MNO^'s data service provided, e.g., if the tethered traffic represents a high percentage with respect to the total traffic volume, block the tethered traffic, block based on the number of tethering devices, notify user, e.g., through SMS, e.g. if a subscriber is doing tethering from multiple devices, for example, over the maximum number of allowed tethering devices, change the QoS, e.g., low QoS or BW limitation, and/or report it. If the confidence level is medium: traffic steering, e.g., to steer a copy of the tethered traffic towards an offline analytics engine. The third node 113 may additionally or alternatively be enabled to store as subscriber data, for each identified device, an indication of being a subscriber and/or device where tethering has been detected and the corresponding tethering information, e.g., the percentage of tethered traffic or number of tethering devices. The information regarding tethering, e.g., as the Tetheringlnfo parameter, stored in the first second node 114 may be used in subsequent sessions for the identified device, e.g., to continue monitoring Tethering for the identified device, e.g., via UE-ID and, if the same behavior is found and/or if the accumulated Tethering volume exceeds a configured threshold, the user may be notified accordingly. By enabling the third node 113 to obtain information about tethering behavior, the performance of the communications system 100 may be enabled to be improved, as the result may enable the third node 113 to manage the traffic in the communications system 100, for example, if the load of the communications system 100 exceeds a certain threshold and the amount of traffic may need to be controlled to ensure a certain QoS for devices operating in certain areas, at a certain time, etc... so that the resources of the communications system 100 may be optimally distributed.

Embodiments of a computer-implemented method performed by the second node 112, 114, 115, 131, will now be described with reference to the flowchart depicted in Figure 4. The method may be understood to be for handling tethering. The second node 112, 114, 115, 131 operates in the communications system 100.

The method may comprise the following actions. Several embodiments are comprised herein. In some embodiments, the method may comprise all actions. In other embodiments, the method may comprise two or more actions. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example may be tacitly assumed to be present in another example and it will be obvious to a person skilled in the art how those components may be used in the other examples. In Figure 4, optional actions are depicted with dashed lines.

The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the first node 111 and will thus not be repeated here to simplify the description. For example, in some embodiments, the first node 111 may be a NWDAF, and the second node 112 may one of: a UPF, a UDR, and the first device 131.

Action 401

In this Action 401 , the second node 112 receives an indication from the first node 111 operating in the communications system 100. The indication requests subscription to an event to receive information indicative of whether or not the one or more devices 130 operating in the communications system 100 are being tethered.

Action 401 may be one of three different actions: Action 401a, 401b and 401c, based on the which node the second node 112 may be, as follows.

Action 401a. In some embodiments wherein the second node 112 is the first second node 114, in the receiving 401a, the received indication may be understood to be the second indication. The second indication may request the subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered.

In some of these embodiments, the first information may indicate the historic tethering information of the one or more devices 130, and the first information may indicate at least the one or more identifiers of the one or more devices 130.

In some embodiments, the first node 111 may be a NWDAF, the first second node 114 may be a UDR.

Action 401b. In some embodiments wherein the second node 112 is a second second node 115, in the receiving 401b, the received indication may be understood to be the third indication. The third indication may request subscription to the first event to receive the second information of the information indicative of whether or not the one or more of devices 130 are being tethered.

The second information may indicate at least one of: i) the first identifier of the requested first event, ii) the protocol metrics, iii) the one or more applications; and the one or more identifiers of the one or more devices 130.

In some embodiments, the first node 111 may be a NWDAF and the second second node 115 may be a UPF. Action 401c. In some embodiments wherein the second node 112 is the third second node, wherein the third second node is the first device 131 of the one or more devices 130, in the receiving 401c, the received indication may be understood to be the fourth indication. The fourth indication may be understood to request the subscription to the second event to receive the third information indicative of whether or not the first device 131 is being tethered.

The third information may indicate at least one of: i) the second identifier of the requested second event, ii) the one or more applications, and iii) the identifier of the first device 131.

Action 402

In this Action 402, the second node 112 sends, in response to the received indication, another indication. The another indication indicates the requested information.

Action 402 may be one of three different actions: Action 402a, 402b and 402c, based on the which node the second node 112 may be, as follows.

Action 402a. In some embodiments wherein the second node 112 is the first second node 114, in the sending 402a, the another indication may be understood to be the fifth indication. The fifth indication may indicate the requested first information.

Action 402b. In some embodiments wherein the second node 112 is a second second node 115, in the sending 402b, the another indication may be understood to be the seventh indication. The seventh indication may indicate the requested second information.

In some embodiments, the first node 111 may be a NWDAF and the second second node 115 may be a UPF.

Action 402c. In some embodiments wherein the second node 112 is the third second node, wherein the third second node is the first device 131 of the one or more devices 130, in the sending 402c, the another indication may be understood to be the sixth indication. The sixth indication may be understood to indicate the requested third information. The third information may indicate at least one of: i) the second identifier of the requested second event, ii) the one or more applications, and iii) the identifier of the first device 131.

Embodiments of a computer-implemented method, performed by the communications system 100, will now be described with reference to the flowchart depicted in Figure 5. The method may be understood to be for handling tethering. The communications system 100 comprises the first node 111 and the one or more second nodes 112.

The method may comprise the actions described below. In some embodiments some of the actions may be performed. In some embodiments all the actions may be performed. In Figure 5, optional actions are indicated with a dashed box. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example may be tacitly assumed to be present in another example and it will be obvious to a person skilled in the art how those components may be used in the other examples.

The detailed description of the Actions depicted in Figure 5 may be understood to correspond to that already provided when describing the actions performed by each of the first node 111 and the second node 112, and will therefore not be repeated here. Any of the details and/or embodiments already described earlier may be understood to equally apply to the description below. For example, in some embodiments, the first node 111 may be an NWDAF, the third node 113 may be a PCF or an OAM, and the one or more second nodes 112 may be at least one of: a UPF, a UDR and the device 131.

Action 501

This Action 501, which corresponds to Action 301, comprises, receiving, by the first node 111 operating in the communications system 100, the first indication from the third node 113. The first indication may request to receive the one or more analytics on whether or not the one or more of devices 130 are being tethered. The first indication may indicate: i) the one or more applications; and ii) the one or more identifiers of one or more devices 130.

Action 502

In some embodiments, the method may comprise, in this Action 502, which corresponds to Action 302, sending 502, by the first node 111 , the second indication to the first second node 114 of the one or more second nodes 112. The second indication may request the subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered.

Action 503

In some embodiments, the method may comprise, in this Action 503, which corresponds to Action 303, sending, by the first node 111 , the third indication to the second second node 115 of the one or more second nodes 112. The third indication may request subscription to the first event to receive the second information of the information indicative of whether or not the one or more of devices 130 are being tethered.

Action 504

In some embodiments, the method may comprise, in this Action 504, which corresponds to Action 304, sending, by the first node 111 , the fourth indication to the third second node, the third second node being the first device 131 of the one or more devices 130. The fourth indication may request the subscription to the second event to receive the third information indicative of whether or not the first device 131 is being tethered.

In some embodiments, the sending 502, 503, 504 of at least one of the second indication, the third indication and the fourth indication may be triggered by the receiving 501 of the first indication.

Action 505

This Action 505, which corresponds to Action 401, comprises receiving 505, by the one or more second nodes 112, the indication from the first node 111. The indication requests the subscription to an event to receive information indicative of whether or not the one or more devices 130 operating in the communications system 100 are being tethered.

Action 505 may be one of three different actions: Action 505a, 505b and 505c, based on the which node the second node 112 may be, as follows.

Action 505a. In some embodiments wherein the second node 112 is the first second node 114, in the receiving 505a by the second node 112, the received indication may be understood to be the second indication. The second indication may request the subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered.

In some of these embodiments, the first information may indicate the historic tethering information of the one or more devices 130, and the first information may indicate at least the one or more identifiers of the one or more devices 130. In some embodiments, the first node 111 may be a NWDAF, the first second node 114 may be a UDR.

Action 505b. In some embodiments wherein the second node 112 is a second second node 115, in the receiving 505b by the second node 112, the received indication may be understood to be the third indication. The third indication may request the subscription to the first event to receive the second information of the information indicative of whether or not the one or more of devices 130 are being tethered.

Action 505c. In some embodiments wherein the second node 112 is the third second node, wherein the third second node is the first device 131 of the one or more devices 130, in the receiving 505c by the second node 112, the received indication may be understood to be the fourth indication. The fourth indication may be understood to request the subscription to the second event to receive the third information indicative of whether or not the first device 131 is being tethered.

Action 506

This Action 506, which corresponds to Action 402, comprises, sending 506, by the one or more second nodes 112, in response to the received indication, the another indication. The another indication indicates the requested information.

In this Action 506, the second node 112 sends, in response to the received indication, another indication. The another indication indicates the requested information.

Action 506 may be one of three different actions: Action 506a, 506b and 506c, based on the which node the second node 112 may be, as follows.

Action 506a. In some embodiments wherein the second node 112 is the first second node 114, in the sending 506a by the second node 112, the another indication may be understood to be the fifth indication. The fifth indication may indicate the requested first information. In some of these embodiments, the first information may indicate the historic tethering information of the one or more devices 130, and the first information may indicate at least the one or more identifiers of the one or more devices 130.

Action 506b. In some embodiments wherein the second node 112 is a second second node 115, in the sending 506b by the second node 112, the another indication may be understood to be the seventh indication. The seventh indication may indicate the requested second information.

Action 506c. In some embodiments wherein the second node 112 is the third second node, wherein the third second node is the first device 131 of the one or more devices 130, in the sending 506c by the second node 112, the another indication may be understood to be the sixth indication. The sixth indication may be understood to indicate the requested third information.

Action 507

This Action 507, which corresponds to Action 305, comprises receiving, by the first node 111, in response to the sent second indication, the fifth indication from the first second node 114. The fifth indication may indicate the requested first information.

Action 508

In some embodiments, the method may comprise, in this Action 508, which corresponds to Action 306, receiving 508, by the first node 111, in response to the sent fourth indication, the sixth indication from the first device 131. The sixth indication may indicate the requested third information.

Action 509

In some embodiments, the method may comprise, in this Action 509, which corresponds to Action 307, receiving 509, by the first node 111, in response to the sent third indication, the seventh indication from the second second node 115. The seventh indication may indicate the requested second information.

Action 510

In some embodiments, wherein the predictive model may be the ML model, the method may comprise, in this Action 509, which corresponds to Action 307, training, by one of the first node 111 or another node 117 operating in the communications system 100, a machine learning model based on at least a first subset of one or more of: the first information, the second information, and the third information.

Action 511

In some embodiments, the method may comprise, in this Action 511, which corresponds to Action 309, determining, by the first node 111, whether or not the one or more devices 130 are being tethered. The determining in this Action 511 being based on: i) the information gathered by the first node 111 from the one or more second nodes 112, the information being indicative of tethered traffic in the communications system 100, and ii) a predictive model of tethering behavior. The predictive model may be that trained in Action 510.

In some embodiments, the determining in this Action 511 of whether or not the one or more of devices 130 may be being tethered is based on the trained ML model.

In some embodiments, the determining in this Action 511 of whether or not the one or more of devices 130 are being tethered may be triggered by the received first indication.

In some embodiments, the determining in this Action 511 of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be based on the received fifth indication.

In some embodiments, the determining in this Action 511 of whether or not the one or more of devices 130 are being tethered may be based on the received sixth indication.

In some embodiments, the determining in this Action 511 of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be based on the received seventh indication.

Action 512

In some embodiments, the method may comprise, in this Action 512, which corresponds to Action 310, initiating providing the result of the determination to the third node 113 operating in the communications system 100. The third node 113 may then be enabled to trigger towards the first second node 114 a Nudr_Store request message including the following parameters: the identifier for the first device 131, e.g., UE-ID and Tetheringlnfo, including: List of App-IDs, which may identify the App-IDs from which tethering has been run, the number of tethered devices, which may identify the number of tethered devices, and the tethering volume, including the percentage with respect to the total traffic volume. The first second node 114 may then store the Tetheringlnfo in the subscriber data for the first device 131, identified with the UE-ID.

Figure 7 is a signalling diagram depicting a first non-limiting example of embodiments herein illustrating a use case for a supervised training process of the ML model. The steps of this example are detailed below. In this non-limiting example, the first node 111 is a NWDAF, the first second node 114 is a UDR, the second second node 115 is a UPF, the third second node, that is, the first device 131, is a Tethered UE, the second device 141 is a Tethering UE, the fourth node 116 is an Application server. As a preconditions, the tethering traffic may have to be marked with an identifier, e.g., a Tag-ID, e.g., DSCP marking, IP Options header, etc. In step 1, the first node 111 starts the training process for Analytic-ID=Tethering. This may be triggered by the third node 113, e.g., a consumer, such as any NF, e.g., OAM, which may request the first node 111 to trigger the training process relative to the new analytic, Analytic- I D= T ethering. Although it is not shown in the figure, the third node 113 may trigger towards the first node 111, in accordance with Action 301 , a Nnwdaf_T raining_Subscribe request message including the following parameters: Analytic-ID=Tethering, optionally, a list of App-ID which indicates the App-ID/s which are the target for tethering, and/or, optionally, the UE-ID or list of UE-ID, UE-Group-ID or list of UE-Group-ID, AnyUE. This indicates the UE/s which are the target for tethering analytics. When not present, AnyUE applies. In the example shown in the sequence diagram of Figure 6, this field is set to the first device 131, that is, a certain UE, by including its UE-ID. Optionally, the Tag-ID may be included, which indicates that tethering traffic is marked with Tag-ID. It is optional as it is also possible that the Tag-ID value is preconfigured, specifically, by the first device 131, i.e., the tethering UE, to mark the traffic with Tag-ID, and/or by the second second node 115, to detect tethering traffic which is marked with Tag-ID. In steps 2 and 3, the first node 111, in accordance with Action 303 and Action 503, triggers data collection from the second second node 115, specifically to retrieve information relative to protocol metrics for the UE-ID. In order to do this, the first node 111 triggers a Nupf_EventExposure_Subscribe request message including the following parameters: Event- ID=ProtocolMetrics, optionally, the list of App-ID, which indicates the App-ID/s for which protocol metrics are required, the UE-ID, which indicates the target UE/s for this event, and optionally, the Tag-ID, which indicates that tethering traffic is marked with Tag-ID. It is optional as it is also possible that the Tag-1 D value is preconfigured at the second second node 115. The second second node 115 receives the third indication in agreement with Action 401b and Action 505b. In step 4, the second second node 115 answers the request message in Step 3 with a successful response, accepting the request. In steps 5 and 6, the first node 111, in accordance with Action 304 and 504, triggers data collection from the first device 131, specifically to retrieve information relative to active (OS) applications for UE-ID. In order to do this, the first node 111 triggers a Nue_EventExposure_Subscribe request message including the following parameters: Event-ID=OSApplications, optionally the list of App-ID, which indicates the App-ID/s for which this event applies to, and the UE-ID, which indicates the target UE/s for this event. At step 7, the first device 131 answers the request message in Step 6 with a successful response, accepting the request. At step 8, a user starts an application, e.g., example.com, from the first device 131, that is, the main UE, the Tethered UE. The first device 131 detects the request from the application client and gathers data for the Event- ID=OSApplications. In particular, the first device 131 stores the following information, when the list of App-ID is included in the message in Step 6, the first device 131 filters based on that list: the OSApplication-ID, e.g., example.com, for each flow: the Timestamp, indicating the start time for the flow, the 5-tuple, and the volume. At step 9, the first device 131 sends application traffic for example.com. At steps 10 and 11 , the second second node 115 detects application traffic for example.com, which in this case is not marked with Tag-ID and gathers data for Event-ID=ProtocolMetrics. The second second node 115 stores the following information: App-ID, e.g., example.com, and for each detected flow: an indication of whether the flow is tethering or no-tethering, e.g.: tagged, with for example Tag-ID, or not. Tagged, with Tag-ID, may be understood to mean that it is a tethered flow, and non-tagged may be understood to mean it is a non-tethered flow. In this case, as the application traffic in Step 10 is non-tagged, the indication indicates no-tethering. Also stored for each detected flow may be: the Timestamp indicating the start and stop time for the flow, the 5-tuple, the volume, the Protocol-ID, e.g., TCP, UDP, QUIC, etc, the Protocol-Metrics, including the set of values and flags for TCP signaling packets, and also other non-transport related parameters such as HTTP User-Agent, specifically: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc.

Figure 7 is a continuation of the procedure depicted in Figure 6. At step 12, the user starts an application, e.g., example.com, from the second device 141, that is the secondary UE or Tethering UE. At step 13, the second device 141 sends application traffic for example.com marked with Tag-ID. At step 14 and 15, the second second node 115 detects application traffic for example.com, which in this case is marked with Tag-ID and gathers data for Event-1 D=ProtocolMetrics. The second second node 115 may store the following information and may optionally remove the mark Tag-ID before forwarding the traffic towards the application server: App-ID, here example.com, and for each detected flow: an indication of whether the flow is tethering or no-tethering. For example: Tagged, with Tag-ID, or not. Tagged, with Tag-ID, may be understood to mean it is a tethered flow and non-tagged may be understood to mean it is a non-tethered flow. In this case, as the application traffic from Step 14 is tagged, the indication indicates tethering. The second second node 115 may additionally or alternatively store for each detected flow: Timestamp, indicating the start and stop time for the flow, 5-tuple, Volume, Protocol-ID, e.g., TCP, UDP, QUIC, etc, Protocol-Metrics, including the set of values and flags for TCP signaling packets, and also other non-transport related parameters like HTTP User-Agent, specifically: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc. At steps 16 and 17, the first device 131, the tethered UE, continues gathering data for the Event- ID=OSApplications and, at some point, due to e.g., periodic reporting, the first device 131, according to Action 306 and Action 508, reports data for the Event-ID= OSApplications. In order to do that, the first device 131 notifies the first node 111 by triggering an Nue_EventExposure_Notify request message including the following parameters: Event-ID= OSApplications, UE-ID, OSApplicationslnfo. This includes the following information, stored in previous steps: OSApplication-ID, here example.com, and for each flow: timestamp, indicating the start time for the flow, 5-tuple, and volume, optionally differentiating uplink and downlink volume. At step 18, the first node 111 answers the message in step 17 indicating successful operation. At steps 19 and 20, the second second node 115 continues gathering data for Event-ID=ProtocolMetrics and at some point, due to e.g., periodic reporting, the second second node 115, according to Action 506b and Action 402b, reports data for Event- ID=ProtocolMetrics. In order to do that, the second second node 115 notifies the first node 111 by triggering a Nupf_EventExposure_Notify request message including the following parameters: Event-ID=ProtocolMetrics, UE-ID, and ProtocolMetricslnfo. This includes the following information: App-ID, here example.com, and, for each detected flow: the indication of whether the flow is tethering or no-tethering. This may be, for example: Tagged, with Tag-ID, or not. Tagged, with Tag-ID, means it is a tethered flow and non-tagged means it is a non- tethered flow. Also indicated for each detected flow are: timestamp, indicating the start and stop time for the flow, 5-tuple, volume, Protocol-ID, e.g., TCP, UDP, QUIC, etc. In this example, the application example.com uses TCP as transport protocol. In general, this may be TCP, UDP or QUIC. It may be noted that QUIC may be understood to be more than a transport protocol, as it goes over UDP transport protocol, but QUIC includes an “embedded” transport protocol, so QUIC related metrics are possible to be obtained. Included in the ProtocolMetricslnfo, for each detected flow may also be included Protocol-Metrics, including the set of values and flags for TCP signaling packets, and also other non-transport related parameters such as HTTP User-Agent. In this example, as the application example.com uses TCP as transport protocol, the following TCP protocol metrics are proposed, which may be understood to be a non-exhaustive list: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc. The first node 111 receives the seventh indication in accordance with Action 307 and Action 509. At step 21, the first node 111 answers the message in step 22 with a successful response. At step 22, the first node 111, in accordance with Action 308 and Action 510, trains the ML model based on the data collected: tagged and untagged, where tagged may be understood to correspond to data collected from tethered traffic, and untagged may be understood to corresponds to data collected from non-tethered traffic. The resulting ML model may be obtained through supervised ML algorithms such as decision tree, random forest, regression, etc.

Figure 8 is a signalling diagram depicting a second non-limiting example of embodiments herein illustrating a use case where data collection from the second second node 115 is relative to protocol metrics. The steps are detailed as follows. At steps 1 and 2, the third node 113, a consumer such as any NF, e.g. PCF or OAM, subscribes to the first node 111 in relation to a new analytic, Analytic-ID= Tethering, by triggering a Nnwdaf_AnalyticsSubscription_Subscribe request message including the following parameters: Analytic-ID=Tethering, optionally, a list of App-ID and also optionally, UE-ID or list of UE-ID, UE-Group-ID or list of UE-Group-ID, AnyUE. The list of App-ID indicates the App- ID/s which are the target for tethering. As an example, the third node 113 may be interested in Tethering analytics related to video streaming applications, e.g., the third node 113 may want to know the percentage of subscribers running video streaming through tethered devices. In case no App-ID is included, that is, in case the list is empty, it means all user traffic is subject to this analytic. UE-ID or list of UE-ID, UE-Group-ID or list of UE-Group-ID, AnyUE indicates the UE/s which are the target for tethering analytics. When not present, AnyUE may be understood to apply. In the example Use Case shown in the sequence diagram of Figure 8, this field is set to a certain UE (UE-ID). The first node 111 receives the first indication according to Action 301 and Action 501. At step 3, the first node 111 answers the request message in step 2 with a successful response, accepting the request. At steps 4 and 5, the first node 111 triggers data collection from the second second node 115. In order to do this, the first node 111 requests in accordance with Action 302 and Action 502, the first second node 114 to provide the subscriber data relative to UE-ID. In order to do this, the first node 111 triggers a Nudr_Query request message indicating UE-ID as parameter, and optionally also including the list of App-ID. The first second node 114 receives the second indication in accordance with Action 401a and Action 505a. At step 6, the first second node 114, in accordance with Action 402a and Action 506a, returns the subscriber data and/or application data for UE-ID, including historic tethering related information for UE-ID. Additionally, the first node 111 may retrieve the subscriber identifier, e.g., SUPI/IMSI, the subscriber public identifier, e.g., PUI/MSISDN, and/or device identifier, e.g., PEI/IMEI for the UE-ID session. At steps 7 and 8, the first node 111, in accordance with Action 303 and Action 503, triggers data collection from the second second node 115, specifically to retrieve information relative to protocol metrics for UE-ID. In order to do this, the first node 111 triggers a Nupf_EventExposure_Subscribe request message including the following parameters: Event- ID=ProtocolMetrics, optionally, list of App-ID, which this indicates the App-ID/s for which protocol metrics are required, and UE-ID, which indicates the target UE/s for this event. At step 9, the second second node 115 answers the request message in step 8 with a successful response accepting the request. At steps 10 and 11 , the first node 111, in accordance with Action 304 and Action 504, triggers data collection from the first device 131, specifically to retrieve information relative to active (OS) applications for the UE-ID. In order to do this, the first node 111 triggers a Nue_EventExposure_Subscribe request message including the following parameters: Event-ID=OSApplications, optionally list of App-ID, which indicates the App-ID/s for which this event applies to, and UE-ID. This indicates the target UE/s for this event. At step 12, the first device 131 answers the request message in step 11 with a successful response accepting the request.

Figure 9 is a continuation of the procedure depicted in Figure 8. At step 13, the first device 131 starts an application, here example.com, from the first device 131, that is, the main UE or Tethered UE. The first device 131 detects the request from the application client and gathers data for Event-ID=OSApplications. In particular, the first device 131 stores the following information, which when list of App-ID is included in the message in step 11, the first device 131 filters based on that list: OSApplication-ID, here example.com, and for each flow: Timestamp, indicating the start time for the flow, and 5-tuple, volume. At step 14, the first device 131 sends application traffic for example.com. At steps 15 and 16, the second second node 115 detects application traffic for example.com and gathers data for Event- ID=ProtocolMetrics. The second second node 115 stores the following information: App-ID, here example.com, and for each detected flow: timestamp, indicating the start and stop time for the flow, 5-tuple, volume, Protocol-ID, e.g., TCP, UDP, QUIC, etc, and Protocol-Metrics. Protocol-Metrics includes the set of values and flags for TCP signaling packets, and also other non-transport related parameters like HTTP User-Agent, specifically: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc. At step 17, the first device 131 starts an application, e.g., example.com, from the second device 141, that is, the secondary UE or Tethering UE. At step 18, the second device 141 sends application traffic for example.com. At steps 19 and 20, the second second node 115 detects application traffic for example.com and gathers data for Event-ID=ProtocolMetrics.

The second second node 115 stores the following information: App-ID, here example.com, and for each detected flow: timestamp, indicating the start and stop time for the flow, 5-tuple, volume, Protocol-ID, e.g., TCP, UDP, QUIC, etc, and Protocol-Metrics, including the set of values and flags for TCP signaling packets, and also other non-transport related parameters like HTTP User-Agent, specifically: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, and etc. At steps 21 and 22, the first device 131 continues gathering data for Event-ID=OSApplications and at some point, e.g., in case of periodic reporting, the first device 131, in accordance with Action 306 and Action 508, reports data for Event-ID= OSApplications. In order to do that, the first device 131 notifies the first node 111 by triggering a Nue_EventExposure_Notify request message including the following parameters: Event-ID= OSApplications, UE-ID, and OSApplicationslnfo, which includes the following information, stored in previous steps: OSApplication-ID, here example.com, and for each flow: timestamp, indicating the start time for the flow, 5-tuple, and volume, optionally differentiating uplink and downlink volume.

Figure 10 is a continuation of the procedure depicted in Figure 9. At step 23, the first node 111 answers the message in step 22 indicating successful operation. At steps 24 and 25, the second second node 115 continues gathering data for Event-ID=ProtocolMetrics and at some point, e.g., in case of periodic reporting, the second second node 115, in accordance with Action 402b and Action 506b, reports data for Event-ID=ProtocolMetrics. In order to do that, the first device 131 notifies the first node 111 by triggering Nupf_EventExposure_Notify request message including the following parameters: Event-ID=ProtocolMetrics, UE-ID, and ProtocolMetricslnfo. ProtocolMetricslnfo includes the following information: App-ID, here example.com, and for each detected flow: timestamp, indicating the start and stop time for the flow, 5-tuple, volume, and Protocol-ID, e.g., TCP, UDP, QUIC, etc. In this example, the application, e.g., example.com, uses TCP as transport protocol. In general, this may be TCP, UDP or QUIC. Also included in ProtocolMetricslnfo may be Protocol-Metrics, including the set of values and flags for TCP signaling packets, and also other non-transport related parameters like HTTP User-Agent. In this example, as the application example.com uses TCP as transport protocol, the following TCP protocol metrics are proposed, which may be understood o be a non-exhaustive list: IP Packet length, Initial TTL value, TCP window length, TCP window size scale, TCP MSS, TCP Option Selective ACK, TCP Option Timestamp, TCP Option EOL, TCP Option NOP count, HTTP User-Agent, etc. The seventh indication is received by the first node 111 in accordance with Action 307 and Action 509. At step 26, the first node 111 answers the message in step 25 with a successful response. At step 27, the first node 111 produces analytics based on the data collected from the first second node 114, the second second node 115 and the first device 131. To detect tethering, the the first node 111, in accordance with Action 309 and Action 511 , uses a Machine Learning model obtained through the training process described in Figure 6 and Figure 7. Additionally, the first node 111 may search for unexpected or uncorrelated data that is indicative of tethering. As an example, the first node 111 may run the following logic. By analyzing both the device identifier, e.g., PEI/IMEI, specifically the TAC to identify smart vs. non-smart devices, and the protocol metrics, e.g.,

TCP related parameters, reported by the second second node 115, the first node 111 may detect tethering, on a per application basis, through OS fingerprinting techniques. In case of data collection both from the first device 131 and the second second node 115, the first node 111 may also correlate the the second second node 115 and the first device 131 events, e.g., by analyzing both timestamps and volume, if the OSApplication-IDs reported from the Tethered the first device 131 do not match with the App-IDs detected by UPF, the NWDAF may determine tethering for App-ID. Based on the above, the first node 111 may determine that tethering is happening and may store the following information, on a per UE-ID basis: List of App-IDs, which identifies the App-IDs from which tethering has been run, number of tethered devices, which identifies the number of tethered devices, and tethering volume, including the percentage with respect to the total traffic volume. At step 28, based on the above, the first node 111, in accordance with Action 310 and Action 512, notifies the third node 113 by triggering a Nnwdaf_AnalyticsSubscription_Notify request message including the following parameters: Analytic-ID=Tethering, and List of UE-IDs, which identifies which UE-IDs have been found to use tethering. Each UE-ID may include the subscriber identifier, e.g., SUPI/IMSI, the subscriber public identifier, e.g., PUI/MSISDN, and/or device identifier, e.g., PEI/IMEI. In this example a single UE-ID is included. Further included in the message sent to the third node 113 is the AnalyticResult. This includes the following information, stored in step 27 above: List of App-IDs, which identifies the App-IDs from which tethering has been run, number of tethered devices, which identifies the number of tethered devices, e.g., in case the analytic is for AnyUE, the average number of tethered devices, and tethering volume, including the percentage with respect to the total traffic volume. This may be used e.g., to determine how much traffic is tethered on a per global basis, on a per UE-ID basis and/or on a per application basis. At step step 29, the third node 113 answers the message in step 28 with a successful response. At steps 30 and 31 , the third node 113 applies the corresponding actions based on the AnalyticResult, in this example, to store in the subscriber profile an indication of a subscriber doing tethering and the corresponding tethering related information. In order to do this, the third node 113 triggers towards the first second node 114 a Nudr_Store request message including the following parameters: UE-ID, and Tetheringlnfo, including: List of App- IDs, which identifies the App-IDs from which tethering has been run, number of tethered devices, which identifies the number of tethered devices, and Tethering volume, including the percentage with respect to the total traffic volume. At step 35, the first second node 114 stores the Tetheringlnfo in the subscriber data for UE-ID. At step 36, the first second node 114 answers the message in step 34 with a successful response. Although not depicted in the sequence diagram of Figure 10, many different actions may be triggered by the third node 113, e.g., PCF or OAM, based on the AnalyticResult. For example, improve MNO^'s data service contract, e.g., if the tethered traffic represents a high percentage with respect to the total traffic volume, the third node 113 may offer subscriber/s doing tethering a specific tethering bundle, block the tethered traffic, block based on the number of tethering devices, notify the user, e.g., through SMS, e.g. if a subscriber is doing tethering from multiple devices over the maximum number of allowed tethering devices, charging, by applying a different tariff or Rating Group (RG), change the QoS, e.g., low QoS or BW limitation, report it, if confidence level is medium: traffic steering, e.g., to steer a copy of the tethered traffic towards an offline analytics engine, store as subscriber data, e.g., for each UE-ID, an indication of being a subscriber/device where tethering has been detected and the corresponding tethering information, e.g., percentage of tethered traffic or number of tethering devices. The Tetheringlnfo stored in the first second node 114 may be used in subsequent sessions for UE- ID, e.g., to continue monitoring Tethering for UE-ID and, if the same behavior is found and/or if the accumulated, tethering volume exceeds a configured threshold, the user may be notified accordingly.

Figure 11 is a signalling diagram depicting a third non-limiting example of embodiments herein illustrating a use case where data collection from the second second node 115 is relative to mirrored data. The steps are the same as in Figure 8 - Figure 10, with the exception of the changes described below. At steps 7 and 8, the first node 111 triggers data collection from the second second node 115, specifically to retrieve mirrored data, that is, raw IP packets, for the indicated UE-ID. In order to do this, the first node 111, in accordance with Action 303 and Action 503, triggers a Nupf_EventExposure_Subscribe request message including the following parameters: Event-ID=Mirroring, optionally, list of App-ID, which indicates the App-ID/s for which mirrored data is required, and UE-ID, which indicates the target UE/s for this event.

Figure 12 is a continuation of the procedure depicted in Figure 11. At steps 15 and 16, the second second node 115 detects application traffic, generates a duplicate for each packet and stores it for Event-ID=Mirroring. The second second node 115 stores the following information: App-ID, here example.com, and for each detected flow: Timestamp, indicating the start and stop time for the flow, and raw IP packets for the whole flow. At step steps 19 and 20, the second second node 115 detects application traffic, generates a duplicate for each packet and stores it for Event-ID=Mirroring. The second second node 115 stores the following information: App-ID, here example.com, and for each detected flow: Timestamp, indicating the start and stop time for the flow, and Raw IP packets for the whole flow.

Figure 13 is a continuation of the procedure depicted in Figure 12. At step 24 and 25, the second second node 115 continues gathering data for Event- 1 D= Mirroring and at some point, in case of e.g., periodic reporting, the second second node 115 reports data for Event- ID=Mirroring. In order to do that, the second second node 115, in accordance with Action 307 and Action 509, notifies the first node 111 by triggering Nupf_EventExposure_Notify request message including the following parameters: Event-ID=Mirroring, UE-ID, and Mirroringlnfo. Mirroringlnfo includes the following information: App-ID, here example.com, and for each detected flow: timestamp, indicating the start and stop time for the flow, and raw IP packets for the whole flow. At step 27, the first node 111, in accordance with Action 309 and Action 511 , produces analytics based on the data collected from the first second node 114, the second second node 115 and the first device 131. To detect tethering, the first node 111 uses a Machine Learning model, obtained through the training process described in Figure 6- Figure 7. Additionally, the first node 111 may search for unexpected or uncorrelated data that is indicative of tethering. As an example, the first node 111 may run the following logic. By analyzing both the device identifier, e.g., PEI/IMEI, specifically the TAC, to identify smart vs. non-smart devices, and the mirrored data reported by the second second node 115, the first node 111 may detect tethering, on a per application basis, through OS fingerprinting techniques. In case of data collection both from the first device 131and the second second node 115, the first node 111 may also correlate the second second node 115 and the first device 131 events, e.g., by analyzing both timestamps and volume, if the OSApplication-IDs reported from the first device 131 do not match with the App-IDs detected by the second second node 115, the first node 111 may determine tethering for App-ID. Based on the above, the first node 111 determines that Tethering is happening and stores the following information, on a per UE-ID basis: List of App-IDs, which identifies the App-IDs from which tethering has been run, number of tethered devices , which identifies the number of tethered devices, and tethering volume, including the percentage with respect to the total traffic volume.

As a summarized overview of the foregoing, embodiments herein may be understood to describe a mechanism which may be understood to allow a network operator to detect and control tethering scenarios in a simple an efficient way, based on analytics, which may be provided by a first node 111 such as, e.g., a NWDAF.

The most relevant advantages of the embodiments herein may be understood to be that they allow the operator of may network to support tethering detection and control in a simple an efficient way, by identifying the amount of tethered traffic in the network of the MNO, and which subscribers, devices and applications may be responsible for.

Some additional example use cases showing the advantages of embodiments herein may be that if the tethered traffic in the of network the MNO represents, e.g., 20% of the total traffic, determined according to embodiments herein, this may be considered to be a significant amount, and may give a hint to may MNO on the need to control this traffic, e.g., by taking actions. This, global, information may be useful for the MNO to take the corresponding decisions, e.g., to improve the data service contract of the MNO, allowing individual subscribers to use tethering within the network of the MNO, by creating a specific tethering bundle with an extra charge on top of the general Internet bundle. This bundle may be adjusted over time, e.g., if there is a trend for doing tethering from an increased number of devices, more granular tethering bundles may be offered.

Additionally, embodiments herein may be understood to allow to identify which subscribers may be doing tethering in their sessions, so they may be offered accordingly on a per individual basis.

Figure 14 depicts two different examples in panels a) and b), respectively, of the arrangement that the first node 111 may comprise to perform the method actions described above in relation to Figure 3, and/or Figures 5-13. In some embodiments, the first node 111 may comprise the following arrangement depicted in Figure 14a. The first node 111 may be understood to be for handling tethering. The first node 111 is configured to operate in the communications system 100.

Several embodiments are comprised herein. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. In Figure 14, optional boxes are indicated by dashed lines. The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the first node 111 and will thus not be repeated here. For example, the first node 111 may be configured to be a NWDAF, the third node 113 may be configured to be PCF, or an OAM, and the one or more second nodes 112 may be configured to be at least one of: a UPF and a UDR.

The first node 111 is configured to, e.g. by means of a determining unit 1401 within the first node 111 configured to, determine whether or not one or more devices 130 configured to operate in the communications system 100 are being tethered. The determining is configured to be based on the information configured to be gathered by the first node 111 from one or more second nodes 112 configured to operate in the communications system 100. The information is configured to be indicative of tethered traffic in the communications system 100. The determining is also configured to be based on the predictive model of tethering behavior.

The first node 111 is also configured to, e.g. by means of an initiating unit 1402 within the first node 111 configured to initiate providing a result of the determination to the third node 113 configured to operate in the communications system 100.

In some embodiments, the first node 111 may be configured to, e.g. by means of a receiving unit 1403 within the first node 111 configured to, receive the first indication from the third node 113. The first indication may be configured to request to receive the one or more analytics on whether or not the one or more of devices 130 are being tethered. The first indication may be configured to indicate: i) the one or more applications; and ii) the one or more identifiers of the one or more devices 130. The determining of whether or not the one or more of devices 130 are being tethered may be configured to be triggered by the first indication configured to be received.

In some embodiments, the first node 111 being further configured to, e.g. by means of a sending unit 1404 within the first node 111 configured to, at least one of: a) send the second indication to the first second node 114 of the one or more second nodes 112; the second indication being configured to request subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered, b) send the third indication to the second second node 115 of the one or more second nodes 112; the third indication being configured to request subscription to the first event to receive second information of the information indicative of whether or not the one or more of devices 130 are being tethered, and c) send the fourth indication to the third second node; the third second nod being the first device 131 of the one or more devices 130; the fourth indication being configured to request subscription to the second event to receive third information indicative of whether or not the first device 131 is being tethered.

In some embodiments, the sending of at least one of the second indication, the third indication and the fourth indication may be configured to be triggered by the receiving of the first indication.

In some embodiments, the first node 111 may be further configured to, e.g. by means of the receiving unit 1403 within the first node 111 configured to, at least one of: a) receive, in response to the second indication configured to be sent, the fifth indication from the first second node 114; the fifth indication may be configured to indicate the requested first information; the determining of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be configured to be based on the fifth indication configured to be received, b) receive, in response to the fourth indication configured to be sent, the sixth indication from the first device 131; the sixth indication may be configured to indicate the third information configured to be requested; the determining of whether or not the one or more of devices 130 are being tethered may be configured to be based on the sixth indication configured to be received, and c) receive, in response to the third indication configured to be sent, the seventh indication from the second second node 115; the seventh indication may be configured to indicate the second information configured to be requested; the determining of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be configured to be based on the seventh indication configured to be received.

In some embodiments, at least one of: a) the first information may be configured to indicate historic tethering information of the one or more devices 130; wherein the first information may be configured to indicate at least the one or more identifiers of the one or more devices 130; b) the second information may be configured to indicate at least one of: i) the first identifier of the requested first event; ii) the protocol metrics; iii) the one or more applications; and iv) the one or more identifiers of the one or more devices 130; and c) the third information may be configured to indicate at least one of: i) the second identifier of the second event configured to be requested; ii) the one or more applications; and iii) the identifier of the first device 131.

In some embodiments, the predictive model may be configured to be a machine-learning model, and the first node 111 may be further configured to, e.g. by means of a training unit 1405 within the first node 111 configured to, train the machine-learning model based on at least the first subset of the one or more of: the first information, the second information, and the third information. The determining of whether or not the one or more of devices 130 are being tethered may be configured to be based on the machine-learning model configured to be trained.

The embodiments herein may be implemented through one or more processors, such as a processor 1406 in the first node 111 depicted in Figure 14, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the first node 111. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the first node 111.

The first node 111 may further comprise a memory 1407 comprising one or more memory units. The memory 1407 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the first node 111.

In some embodiments, the first node 111 may receive information from, e.g., the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, and/or the first device 131, through a receiving port 1408. In some examples, the receiving port 1408 may be, for example, connected to one or more antennas in the first node 111. In other embodiments, the first node 111 may receive information from another structure in the communications system 100 through the receiving port 1408. Since the receiving port 1408 may be in communication with the processor 1406, the receiving port 1408 may then send the received information to the processor 1406. The receiving port 1408 may also be configured to receive other information.

The processor 1406 in the first node 111 may be further configured to transmit or send information to e.g., the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, the first device 131, and/or another structure in the communications system 100, through a sending port 1409, which may be in communication with the processor 1406, and the memory 1407.

Those skilled in the art will also appreciate that any of the units 1401-1405 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor 1406, perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Any of the units 1401-1405 described above may be the processor 1406 of the first node 111 , or an application running on such processor.

Thus, the methods according to the embodiments described herein for the first node 111 may be respectively implemented by means of a computer program 1410 product, comprising instructions, i.e., software code portions, which, when executed on at least one processor 1406, cause the at least one processor 1406 to carry out the actions described herein, as performed by the first node 111. The computer program 1410 product may be stored on a computer-readable storage medium 1411. The computer-readable storage medium 1411, having stored thereon the computer program 1410, may comprise instructions which, when executed on at least one processor 1406, cause the at least one processor 1406 to carry out the actions described herein, as performed by the first node 111. In some embodiments, the computer-readable storage medium 1411 may be a non-transitory computer-readable storage medium, such as a CD ROM disc, a memory stick, or stored in the cloud space. In other embodiments, the computer program 1410 product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 1411, as described above.

The first node 111 may comprise an interface unit to facilitate communications between the first node 111 and other nodes or devices, e.g., the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, the first device 131, and/or another structure in the communications system 100. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the first node 111 may comprise the following arrangement depicted in Figure 14b. The first node 111 may comprise a processing circuitry 1406, e.g., one or more processors such as the processor 1406, in the first node 111 and the memory 1407. The first node 111 may also comprise a radio circuitry 1412, which may comprise e.g., the receiving port 1408 and the sending port 1409. The processing circuitry 1406 may be configured to, or operable to, perform the method actions according to Figure 3, and/or Figures 5-13, in a similar manner as that described in relation to Figure 14a. The radio circuitry 1412 may be configured to set up and maintain at least a wireless connection with the the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, the first device 131, and/or another structure in the communications system 100.

Hence, embodiments herein also relate to the first node 111 operative for handling tethering, the first node 111 being operative to operate in the communications system 100.

The first node 111 may comprise the processing circuitry 1406 and the memory 1407, said memory 1407 containing instructions executable by said processing circuitry 1406, whereby the first node 111 is further operative to perform the actions described herein in relation to the first node 111, e.g., in Figure 3, and/or Figures 5-13.

Figure 15 depicts two different examples in panels a) and b), respectively, of the arrangement that the second node 112, 114, 115, 131 may comprise to perform the method actions described above in relation to Figure 4, and/or Figures 5-13. In some embodiments, the second node 112, 114, 115, 131 may comprise the following arrangement depicted in Figure 15a. The second node 112, 114, 115, 131 may be understood to be for handling tethering. The second node 112, 114, 115, 131 may be configured to operate in the communications system 100.

Several embodiments are comprised herein. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. In Figure 15, optional boxes are indicated by dashed lines. The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the second node 112, 114, 115, 131 and will thus not be repeated here. For example, the first node 111 may be configured to be a NWDAF and the second node 112 may be configured to be one of: a UPF and a UDR.

The first node 111 may be configured to be a NWDAF, and the first second node 114 may be configured to be a UDR. In other examples, the first node 111 may be configured to be a NWDAF, and the second second node 115 may be configured to be a UPF. The first node 111 may be configured to be a NWDAF, and the third second node 131 may be configured to be the first device 131.

The second node 112, 114, 115, 131 is configured to, e.g. by means of a receiving unit 1501 within the second node 112, 114, 115, 131 configured to, receive an indication from the first node 111 configured to operate in the communications system 100. The indication is configured to request subscription to the event to receive information indicative of whether or not the one or more devices 130 configured to operate in the communications system 100 are being tethered.

The second node 112, 114, 115, 131 is also be configured to, e.g. by means of a sending unit 1502 within the second node 112, 114, 115, 131 configured to, send, in response to the indication configured to be received, another indication. The another indication may be configured to indicate the information configured to be requested.

In some embodiments, the second node 112, 114 may be configured to be the first second node 114. The received indication may be configured to be the second indication.

The second indication may be configured to request subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered. The another indication may be configured to be the fifth indication. The fifth indication may be configured to indicate the first information configured to be requested.

In some embodiments, the first information may be configured to indicate historic tethering information of the one or more devices 130. The first information may be configured to indicate at least the one or more identifiers of the one or more devices 130.

In some embodiments, wherein the second node 112 may be configured to be the second second node 115, and the received indication may be configured to be the third indication, the third indication may be configured to request subscription to the first event to receive the second information of the information indicative of whether or not the one or more of devices 130 are being tethered. The another indication may be configured to be the seventh indication, the seventh indication may be configured to indicate the second information configured to be requested.

In some embodiments, the second information may be configured to indicate at least one of: the first identifier of the requested first event, the protocol metrics, the one or more applications, and the one or more identifiers of the one or more devices 130.

In some embodiments, wherein the second node 112 may be configured to be the third second node, the third second node may be configured to be a first device 131 of the one or more devices 130, and: i) the received indication may be configured to be the fourth indication; the fourth indication may be configured to request subscription to the second event to receive the third information indicative of whether or not the first device 131 is being tethered, and ii) the another indication may be configured to be the sixth indication; the sixth indication may be configured to indicate the third information configured to be requested.

In some embodiments, the third information may be configured to indicate at least one of: the second identifier of the second event configured to be requested, the one or more applications; and the identifier of the first device 131. The embodiments herein may be implemented through one or more processors, such as a processor 1503 in the second node 112, 114, 115, 131 depicted in Figure 15, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the second node 112, 114, 115, 131. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the second node 112, 114, 115, 131.

The second node 112, 114, 115, 131 may further comprise a memory 1504 comprising one or more memory units. The memory 1504 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the second node 112, 114, 115, 131.

In some embodiments, the second node 112, 114, 115, 131 may receive information from, e.g., the first node 111, the other one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, and/or the first device 131, through a receiving port 1505. In some examples, the receiving port 1505 may be, for example, connected to one or more antennas in the second node 112, 114, 115, 131. In other embodiments, the second node 112, 114, 115, 131 may receive information from another structure in the communications system 100 through the receiving port 1505. Since the receiving port 1505 may be in communication with the processor 1503, the receiving port 1505 may then send the received information to the processor 1503. The receiving port 1505 may also be configured to receive other information.

The processor 1503 in the second node 112, 114, 115, 131 may be further configured to transmit or send information to e.g., the first node 111 , the other of the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, the first device 131, and/or another structure in the communications system 100, through a sending port 1506, which may be in communication with the processor 1503, and the memory 1504.

Those skilled in the art will also appreciate that the units 1501-1502 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor 1503, perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

The units 1501-1502 described above may be the processor 1503 of the second node 112, 114, 115, 131, or an application running on such processor.

Thus, the methods according to the embodiments described herein for the second node 112, 114, 115, 131 may be respectively implemented by means of a computer program 1507 product, comprising instructions, i.e., software code portions, which, when executed on at least one processor 1503, cause the at least one processor 1503 to carry out the actions described herein, as performed by the second node 112, 114, 115, 131. The computer program 1507 product may be stored on a computer-readable storage medium 1508. The computer- readable storage medium 1508, having stored thereon the computer program 1507, may comprise instructions which, when executed on at least one processor 1503, cause the at least one processor 1503 to carry out the actions described herein, as performed by the second node 112, 114, 115, 131. In some embodiments, the computer-readable storage medium 1508 may be a non-transitory computer-readable storage medium, such as a CD ROM disc, a memory stick, or stored in the cloud space. In other embodiments, the computer program 1507 product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 1508, as described above.

The second node 112, 114, 115, 131 may comprise an interface unit to facilitate communications between the second node 112, 114, 115, 131 and other nodes or devices, e.g., the first node 111, the other of the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, the first device 131, and/or another structure in the communications system 100. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the second node 112, 114, 115, 131 may comprise the following arrangement depicted in Figure 15b. The second node 112, 114, 115, 131 may comprise a processing circuitry 1503, e.g., one or more processors such as the processor 1503, in the second node 112, 114, 115, 131 and the memory 1504. The second node 112, 114, 115, 131 may also comprise a radio circuitry 1509, which may comprise e.g., the receiving port 1505 and the sending port 1506. The processing circuitry 1503 may be configured to, or operable to, perform the method actions according to Figure 4, and/or Figures 5-13, in a similar manner as that described in relation to Figure 15a. The radio circuitry 1509 may be configured to set up and maintain at least a wireless connection with the first node 111 , the other of the one or more second nodes 112, the third node 113, the first second node 114, the second second node 115, the fourth node 116, the another node 117, the one or more devices 130, the first device 131, and/or another structure in the communications system 100.

Hence, embodiments herein also relate to the second node 112, 114, 115, 131 operative for handling tethering, the second node 112, 114, 115, 131 being operative to operate in the communications system 100. The second node 112, 114, 115, 131 may comprise the processing circuitry 1503 and the memory 1504, said memory 1504 containing instructions executable by said processing circuitry 1503, whereby the second node 112, 114, 115, 131 is further operative to perform the actions described herein in relation to the second node 112, 114, 115, 131, e.g., in Figure 4, and/or Figures 5-13.

Figure 16 depicts two different examples in panels a) and b), respectively, of the arrangement that the communications system 100 may comprise to perform the method actions described above in relation to Figure 5. The arrangement depicted in panel a) corresponds to that described in relation to panel a) in Figure 14 and Figure 15 for each of the first node 111 and the second node 112, 114, 115, 131, respectively. The arrangement depicted in panel b) corresponds to that described in relation to panel b) in Figure 14 and Figure 15 for each of the first node 111 and the second node 112, 114, 115, 131, respectively. The communications system 100 may be for handling tethering. The communications system 100 comprises the first node 111 and the one or more second nodes 112.

Several embodiments are comprised herein. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. In Figure 16, optional boxes are indicated by dashed lines. The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the communications system 100 and will thus not be repeated here. For example, the first node 111 may be configured to be a NWDAF, the third node 113 may be configured to be PCF, or an OAM, and the one or more second nodes 112 may be configured to be at least one of: a UPF and a UDR.

The communications system 100 is configured to, e.g. by means of the receiving unit 1501 within the second node 112, 114, 115, 131 configured to, receive, by the one or more second nodes 112, an indication from the first node 111. The indication is configured to request subscription to the event to receive information indicative of whether or not the one or more devices 130 configured to operate in the communications system 100 are being tethered.

The communications system 100 is configured to, e.g. by means of the sending unit 1502 within the second node 112, 114, 115, 131 configured to, send, by the one or more second nodes 112, in response to the received indication, another indication, the another indication being configured to indicate the information configured to be requested.

The communications system 100 is configured to, e.g. by means of a determining unit

1401 within the first node 111 configured to, determine, by the first node 111, whether or not one or more devices 130 are being tethered. The determining is configured to be based on the information configured to be gathered by the first node 111 from one or more second nodes 112. The information is configured to be indicative of tethered traffic in the communications system 100. The determining is also configured to be based on the predictive model of tethering behavior.

The communications system 100 is configured to, e.g. by means of the initiating unit

1402 within the first node 111 configured to, initiate providing, by the first node 111, the result of the determination to the third node 113 configured to operate in the communications system 100.

In some embodiments, the predictive model may be configured to be a machine-learning model, and the communications system 100 may be further configured to, e.g. by means of the training unit 1405 within the first node 111 configured to, train, by one of the first node 111 or another node 117 configured to operate in the communications system 100, the machine-learning model based on at least the first subset of the one or more of: the first information, the second information, and the third information. The determining of whether or not the one or more of devices 130 are being tethered may be configured to be based on the machine-learning model configured to be trained.

In some embodiments, the communications system 100 may be configured to, e.g. by means of the receiving unit 1403 within the first node 111 configured to, receive, by the first node 111, the first indication from the third node 113. The first indication may be configured to request to receive the one or more analytics on whether or not the one or more of devices 130 are being tethered. The first indication may be configured to indicate: i) the one or more applications; and ii) the one or more identifiers of the one or more devices 130. The determining of whether or not the one or more of devices 130 are being tethered may be configured to be triggered by the first indication configured to be received. In some embodiments, the communications system 100 may be further configured to, e.g. by means of the sending unit 1404 within the first node 111 configured to, at least one of: a) send, by the first node 111, the second indication to the first second node 114 of the one or more second nodes 112; the second indication being configured to request subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered, b) send, by the first node 111, the third indication to the second second node 115 of the one or more second nodes 112; the third indication being configured to request subscription to the first event to receive the second information of the information indicative of whether or not the one or more of devices 130 are being tethered, and c) send, by the first node 111 , the fourth indication to the third second node; the third second node being configured to be the first device 131 of the one or more devices 130; the fourth indication being configured to request subscription to the second event to receive third information indicative of whether or not the first device 131 is being tethered.

In some embodiments, the second node 112, 114 may be configured to be the first second node 114. In some of such embodiments, in the receiving by the second node 112, the received indication may be configured to be the second indication. The second indication may be configured to request subscription to receive the first information of the information indicative of whether or not the one or more of devices 130 are being tethered. In the sending by the second node 112, the another indication may be configured to be the fifth indication.

The fifth indication may be configured to indicate the first information configured to be requested. In some of such embodiments, the communications system 100 may be further configured to, e.g. by means of the receiving unit 1403 within the first node 111 configured to, receive, by the first node 111, in response to the second indication configured to be sent, the fifth indication from the first second node 114. The fifth indication may be configured to indicate the first information configured to be requested. The determining of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be configured to be based on the fifth indication configured to be received.

In some embodiments, the first information may be configured to indicate historic tethering information of the one or more devices 130, and the first information may be configured to indicate at least the one or more identifiers of the one or more devices 130.

In some embodiments, the second node 112 may be a second second node 115. In some of such embodiments, in the receiving by the second node 112, the indication configured to be received may be configured to be the third indication. The third indication may be configured to request subscription to the first event to receive second information of the information indicative of whether or not the one or more of devices 130 are being tethered. In the sending by the second node 112, the another indication may be configured to be the seventh indication. The seventh indication may be configured to indicate the second information configured to be requested. In some of such embodiments, the communications system 100 may be further configured to, e.g. by means of the receiving unit 1403 within the first node 111 configured to, receive, by the first node 111, in response to the third indication configured to be sent, the seventh indication from the second second node 115. The seventh indication may be configured to indicate the second information configured to be requested. The determining of whether or not the one or more of devices 130 are being tethered by the one or more second devices 140 may be configured to be based on the seventh indication configured to be received.

In some embodiments, the second information may be configured to indicate at least one of: the first identifier of the first event configured to be requested, the protocol metrics, the one or more applications, and the one or more identifiers of the one or more devices 130.

In some embodiments, the second node 112 may be configured to be the third second node wherein the third second node may be configured to be the first device 131 of the one or more devices 130. In some of such embodiments, in the receiving by the second node 112, the indication configured to be received may be configured to be the fourth indication. The fourth indication may be configured to request subscription to the second event to receive third information of the information indicative of whether or not the first device 131 is being tethered. In the sending by the second node 112, the another indication may be configured to be the sixth indication. The sixth indication may be configured to indicate the third information configured to be requested. In some of such embodiments, the communications system 100 may be further configured to, e.g. by means of the receiving unit 1403 within the first node 111 configured to, receive, by the first node 111, in response to the fourth indication configured to be sent, the sixth indication from the first device 131. The sixth indication may be configured to indicate the third information configured to be requested. The determining of whether or not the one or more of devices 130 are being tethered may be configured to be based on the sixth indication configured to be received.

In some embodiments, the third information may be configured to indicate at least one of: the second identifier of the second event configured to be requested, the one or more applications; and the identifier of the first device 131.

The remaining configurations described for the first node 111 and the second node 112, 114, 115, 131 in relation to Figure 16, may be understood to correspond to those described in Figure 14 and Figure 15, respectively, and to be performed, e.g., by means of the corresponding units and arrangements described in Figure 14 and Figure 15, which will not be repeated here.

When using the word "comprise" or “comprising”, it shall be interpreted as non- limiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the invention.

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

As used herein, the expression “at least one of:” followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the “and” term, may be understood to mean that only one of the list of alternatives may apply, more than one of the list of alternatives may apply or all of the list of alternatives may apply. This expression may be understood to be equivalent to the expression “at least one of:” followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the “or” term.

Any of the terms processor and circuitry may be understood herein as a hardware component.

As used herein, the expression “in some embodiments” has been used to indicate that the features of the embodiment described may be combined with any other embodiment or example disclosed herein.

As used herein, the expression “in some examples” has been used to indicate that the features of the example described may be combined with any other embodiment or example disclosed herein.

Reference:

3GPP TS 23.288 v16.6.0 (Dec 2020): Architecture enhancements for 5G System (5GS) to support network data analytics services

Claims

CLAIMS:

1. A computer-implemented method, performed by a first node (111), for handling tethering, the first node (111) operating in the communications system (100), the method comprising:

- determining (309) whether or not one or more devices (130) operating in the communications system (100) are being tethered, the determining (306) being based on: i. information gathered by the first node (111) from one or more second nodes (112) operating in the communications system (100), the information being indicative of tethered traffic in the communications system (100), and ii. a predictive model of tethering behavior, and

- initiating (310) providing a result of the determination to a third node (113) operating in the communications system (100).

2. The computer-implemented method according to claim 1 , the method further comprising:

- receiving (301) a first indication from the third node (113), the first indication requesting to receive one or more analytics on whether or not the one or more of devices (130) are being tethered, the first indication indicating: i. one or more applications; and ii. one or more identifiers of the one or more devices (130); and wherein the determining (309) of whether or not the one or more of devices (130) are being tethered is triggered by the received first indication.

3. The computer-implemented method according to any of claims 1-2, the method further comprising at least one of:

- sending (302) a second indication to a first second node (114) of the one or more second nodes (112), the second indication requesting subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered,

- sending (303) a third indication to a second second node (115) of the one or more second nodes (112), the third indication requesting subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and - sending (304) a fourth indication to a third second node, the third second node being a first device (131) of the one or more devices 130), the fourth indication requesting subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered.

4. The computer-implemented method according to claims 2 and 3, wherein the sending (302, 303, 304) of at least one of the second indication, the third indication and the fourth indication is triggered by the receiving (301) of the first indication.

5. The computer-implemented method according to any of claims 3-4, the method further comprising at least one of:

- receiving (305), in response to the sent second indication, a fifth indication from the first second node (114), the fifth indication indicating the requested first information, and wherein the determining (309) of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is based on the received fifth indication,

- receiving (306), in response to the sent fourth indication, a sixth indication from the first device (131), the sixth indication indicating the requested third information, and wherein the determining (309) of whether or not the one or more of devices (130) are being tethered is based on the received sixth indication, and

- receiving (307), in response to the sent third indication, a seventh indication from the second second node (115), the seventh indication indicating the requested second information, and wherein the determining (309) of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is based on the received seventh indication.

6. The computer-implemented method according to and of claims 3-5, wherein at least one of: a. the first information indicates historic tethering information of the one or more devices (130), and wherein the first information indicates at least the one or more identifiers of the one or more devices (130); b. the second information indicates at least one of: i. a first identifier of the requested first event; ii. protocol metrics; iii. one or more applications; and iv. one or more identifiers of the one or more devices (130); and c. the third information indicates at least one of: i. a second identifier of the requested second event; ii. one or more applications; and iii. an identifier of the first device (131).

7. The computer-implemented method according to any of claims 5-6, wherein the predictive model is a machine-learning model, and wherein method further comprises:

- training (308) the machine-learning model based on at least a first subset of one or more of: the first information, the second information, and the third information, and wherein the determining (309) of whether or not the one or more of devices (130) are being tethered is based on the trained machine-learning model.

8. The method according to any of claims 1-7, wherein the first node (111) is a Network Data Analytics Function, NWDAF, the third node (113), is a Policy Charging Function, PCF, or an Operation Administration and Maintenance, OAM, and the one or more second nodes (112) are at least one of: a User Plane Function, UPF, and a Unified Data Repository, UDR.

9. A computer program (1110), comprising instructions which, when executed on at least one processor (1106), cause the at least one processor (1106) to carry out the method according to any one of claims 1 to 8.

10. A computer-readable storage medium (1111), having stored thereon a computer program (1110), comprising instructions which, when executed on at least one processor (1106), cause the at least one processor (1106) to carry out the method according to any one of claims 1 to 8.

11. A computer-implemented method, performed by a second node (112, 114, 115, 131), for handling tethering, the second node (112, 114, 115, 131) operating in the communications system (100), the method comprising:

- receiving (401) an indication from a first node (111) operating in the communications system (100), the indication requesting subscription to an event to receive information indicative of whether or not the one or more devices (130) operating in the communications system (100) are being tethered, and

- sending (402), in response to the received indication, another indication, the another indication indicating the requested information.

12. The computer-implemented method according to claim 11, wherein the second node (112) is a first second node (114), and wherein: - in the receiving (401a), the received indication is a second indication, the second indication requesting subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- in the sending (402a) the another indication is a fifth indication, the fifth indication indicating the requested first information.

13. The computer-implemented method according to claim 12, wherein the first information indicates historic tethering information of the one or more devices (130), and wherein the first information indicates at least the one or more identifiers of the one or more devices (130).

14. The computer-implemented method according to any of claims 11-13, wherein the second node (112) is a second second node (115), and wherein:

- in the receiving (401b), the received indication is a third indication, the third indication requesting subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- in the sending (402b), the another indication is a seventh indication, the seventh indication indicating the requested second information.

15. The computer-implemented method according to claim 14, wherein the second information indicates at least one of: i. a first identifier of the requested first event; ii. protocol metrics; iii. one or more applications; and iv. one or more identifiers of the one or more devices (130).

16. The computer-implemented method according to any of claims 11-15, wherein the second node (112) is a third second node, wherein the third second node is a first device (131) of the one or more devices (130), and wherein:

- in the receiving (401c), the received indication is a fourth indication, the fourth indication requesting subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered, and

- in the sending (402c), the another indication is a sixth indication, the sixth indication indicating the requested third information. 17. The computer-implemented method according to claim 14, wherein the third information indicates at least one of: i. a second identifier of the requested second event; ii. one or more applications; and iii. an identifier of the first device (131).

18. The method according to any of claims 11-17, wherein the first node (111) is a Network Data Analytics Function, NWDAF, and the second node (112) is one of: a User Plane Function, UPF, and a Unified Data Repository, UDR.

19. The method according to any of claims 12-17, wherein the first node (111) is a Network Data Analytics Function, NWDAF and the first second node (114) is a Unified Data Repository, UDR.

20. The method according to any of claims 14-17, wherein the first node (111) is a Network Data Analytics Function, NWDAF and the second second node (115) is a User Plane Function, UPF.

21. A computer program (1110), comprising instructions which, when executed on at least one processor (1106), cause the at least one processor (1106) to carry out the method according to any one of claims 11 to 20.

22. A computer-readable storage medium (1111), having stored thereon a computer program (1110), comprising instructions which, when executed on at least one processor (1106), cause the at least one processor (1106) to carry out the method according to any one of claims 11 to 20.

23. A computer-implemented method, performed by a communications system (100), for handling tethering, the communications system (100) comprising a first node (111) and a one or more second nodes (112), the method comprising:

- receiving (505), by the one or more second nodes (112), an indication from the first node (111), the indication requesting subscription to an event to receive information indicative of whether or not the one or more devices (130) operating in the communications system (100) are being tethered,

- sending (506), by the one or more second nodes (112), in response to the received indication, another indication, the another indication indicating the requested information, - determining (511), by the first node (111), whether or not the one or more devices (130) are being tethered, the determining (511) being based on: i. the information gathered by the first node (111) from the one or more second nodes (112), the information being indicative of tethered traffic in the communications system (100), and ii. a predictive model of tethering behavior, and

- initiating (512) providing a result of the determination to a third node (113) operating in the communications system (100).

24. The computer-implemented method according to claim 23, wherein the predictive model is a machine-learning model, and wherein method further comprises:

- training (510), by one of the first node (111) or another node (117) operating in the communications system (100), the machine-learning model based on at least a first subset of one or more of: the first information, the second information, and the third information, and wherein the determining (511) of whether or not the one or more of devices (130) are being tethered is based on the trained machine-learning model.

25. The computer-implemented method according to any of claims 23-24, the method further comprising:

- receiving (501), by the first node (111), a first indication from the third node (113), the first indication requesting to receive one or more analytics on whether or not the one or more of devices (130) are being tethered, the first indication indicating: i. one or more applications; and ii. one or more identifiers of the one or more devices (130); and wherein the determining (511) of whether or not the one or more of devices (130) are being tethered is triggered by the received first indication.

26. The computer-implemented method according to any of claims 23-25, the method further comprising at least one of:

- sending (502), by the first node (111), a second indication to a first second node

(114) of the one or more second nodes (112), the second indication requesting subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered,

- sending (503), by the first node (111), a third indication to a second second node

(115) of the one or more second nodes (112), the third indication requesting subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- sending (504), by the first node (111), a fourth indication to a third second node, the third second node being a first device (131) of the one or more devices 130), the fourth indication requesting subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered.

27. The computer-implemented method according to claims 25 and 26, wherein the sending (502, 503, 504) of at least one of the second indication, the third indication and the fourth indication is triggered by the receiving (501) of the first indication.

28. The computer-implemented method according to claim 23-27, wherein the second node (112) is a first second node (114), and wherein:

- in the receiving (505a) by the second node (112), the received indication is a second indication, the second indication requesting subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- in the sending (506a) by the second node (112), the another indication is a fifth indication, the fifth indication indicating the requested first information, and wherein the method further comprises:

- receiving (507), by the first node (111), in response to the sent second indication, a fifth indication from the first second node (114), the fifth indication indicating the requested first information, and wherein the determining (511) of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is based on the received fifth indication.

29. The computer-implemented method according to claim 28, wherein the first information indicates historic tethering information of the one or more devices (130), and wherein the first information indicates at least the one or more identifiers of the one or more devices (130).

30. The computer-implemented method according to any of claims 23-29, wherein the second node (112) is a second second node (115), and wherein:

- in the receiving (505b) by the second node (112), the received indication is a third indication, the third indication requesting subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and - in the sending (506b) by the second node (112), the another indication is a seventh indication, the seventh indication indicating the requested second information, and wherein the method further comprises:

- receiving (509), by the first node (111), in response to the sent third indication, a seventh indication from the second second node (115), the seventh indication indicating the requested second information, and wherein the determining (511) of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is based on the received seventh indication.

31. The computer-implemented method according to claim 30, wherein the second information indicates at least one of: i. a first identifier of the requested first event; ii. protocol metrics; iii. one or more applications; and iv. one or more identifiers of the one or more devices (130).

32. The computer-implemented method according to any of claims 23-31, wherein the second node (112) is a third second node, wherein the third second node is a first device (131) of the one or more devices (130), and wherein:

- in the receiving (505c) by the second node (112), the received indication is a fourth indication, the fourth indication requesting subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered, and

- in the sending (506c) by the second node (112), the another indication is a sixth indication, the sixth indication indicating the requested third information, and wherein the method further comprises:

- receiving (508), by the first node (111), in response to the sent fourth indication, a sixth indication from the first device (131), the sixth indication indicating the requested third information, and wherein the determining (511) of whether or not the one or more of devices (130) are being tethered is based on the received sixth indication.

33. The computer-implemented method according to claim 32, wherein the third information indicates at least one of: i. a second identifier of the requested second event; ii. one or more applications; and iii. an identifier of the first device (131). 34. The method according to any of claims 23-33, wherein the first node (111) is a Network Data Analytics Function, NWDAF, the third node (113), is a Policy Charging Function, PCF, or an Operation Administration and Maintenance, OAM, and the one or more second nodes (112) are at least one of: a User Plane Function, UPF, and a Unified Data Repository, UDR.

35. A first node (111), for handling tethering, the first node (111) being configured to operate in the communications system (100), the first node (111) being further configured to:

- determine whether or not one or more devices (130) configured to operate in the communications system (100) are being tethered, the determining being configured to be based on: i. information configured to be gathered by the first node (111) from one or more second nodes (112) configured to operate in the communications system (100), the information being configured to be indicative of tethered traffic in the communications system (100), and ii. a predictive model of tethering behavior, and

- initiate providing a result of the determination to a third node (113) configured to operate in the communications system (100).

36. The first node (111) according to claim 35, the first node (111) being further configured to:

- receive a first indication from the third node (113), the first indication being configured to request to receive one or more analytics on whether or not the one or more of devices (130) are being tethered, the first indication being configured to indicate: i. one or more applications; and ii. one or more identifiers of the one or more devices (130); and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be triggered by the first indication configured to be received.

37. The first node (111) according to any of claims 35-36, the first node (111) being further configured to at least one of:

- send a second indication to a first second node (114) of the one or more second nodes (112), the second indication being configured to request subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered,

- send a third indication to a second second node (115) of the one or more second nodes (112), the third indication being configured to request subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- send a fourth indication to a third second node, the third second node being a first device (131) of the one or more devices 130), the fourth indication being configured to request subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered.

38. The first node (111) according to claims 36 and 37, wherein the sending of at least one of the second indication, the third indication and the fourth indication is configured to be triggered by the receiving of the first indication.

39. The first node (111) according to any of claims 37-38, the first node (111) being further configured to at least one of:

- receive, in response to the second indication configured to be sent, a fifth indication from the first second node (114), the fifth indication being configured to indicate the requested first information, and wherein the determining of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is configured to be based on the fifth indication configured to be received,

- receive, in response to the fourth indication configured to be sent, a sixth indication from the first device (131), the sixth indication being configured to indicate the third information configured to be requested, and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be based on the sixth indication configured to be received, and

- receive, in response to the third indication configured to be sent, a seventh indication from the second second node (115), the seventh indication being configured to indicate the second information configured to be requested, and wherein the determining of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is configured to be based on the seventh indication configured to be received.

40. The first node (111) according to and of claims 37-39, wherein at least one of: a. the first information is configured to indicate historic tethering information of the one or more devices (130), and wherein the first information is configured to indicate at least the one or more identifiers of the one or more devices (130); b. the second information is configured to indicate at least one of: i. a first identifier of the requested first event; ii. protocol metrics; iii. one or more applications; and iv. one or more identifiers of the one or more devices (130); and c. the third information is configured to indicate at least one of: i. a second identifier of the second event configured to be requested; ii. one or more applications; and iii. an identifier of the first device (131).

41. The first node (111) according to any of claims 39-40, wherein the predictive model is configured to be a machine-learning model, and wherein the first node (111) is further configured to:

- train the machine-learning model based on at least a first subset of one or more of: the first information, the second information, and the third information, and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be based on the machine-learning model configured to be trained.

42. The first node (111) according to any of claims 35-41, wherein the first node (111) is configured to be a Network Data Analytics Function, NWDAF, the third node (113), is configured to be a Policy Charging Function, PCF, or an Operation Administration and Maintenance, OAM, and the one or more second nodes (112) are configured to be at least one of: a User Plane Function, UPF, and a Unified Data Repository, UDR.

43. A second node (112, 114, 115, 131), for handling tethering, the second node (112, 114, 115, 131) being configured to operate in the communications system (100), the second node (112, 114, 115, 131) being further configured to:

- receive an indication from a first node (111) configured to operate in the communications system (100), the indication being configured to request subscription to an event to receive information indicative of whether or not the one or more devices (130) configured to operate in the communications system (100) are being tethered, and - send, in response to the indication configured to be received, another indication, the another indication being configured to indicate the information configured to be requested.

44. The second node (112, 114) according to claim 43, wherein the second node (112) is configured to be a first second node (114), and wherein:

- the received indication is configured to be a second indication, the second indication being configured to request subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- the another indication is configured to be a fifth indication, the fifth indication being configured to indicate the first information configured to be requested.

45. The second node (112, 114) according to claim 44, wherein the first information is configured to indicate historic tethering information of the one or more devices (130), and wherein the first information is configured to indicate at least the one or more identifiers of the one or more devices (130).

46. The second node (112, 115) according to any of claims 43-45, wherein the second node (112) is configured to be a second second node (115), and wherein:

- the received indication is configured to be a third indication, the third indication being configured to request subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- the another indication is configured to be a seventh indication, the seventh indication being configured to indicate the second information configured to be requested.

47. The second node (112, 115) according to claim 46, wherein the second information is configured to indicate at least one of: i. a first identifier of the requested first event; ii. protocol metrics; iii. one or more applications; and iv. one or more identifiers of the one or more devices (130). 48. The second node (112, 131) according to any of claims 43-47, wherein the second node (112) is configured to be a third second node, wherein the third second node is configured to be a first device (131) of the one or more devices (130), and wherein:

- the received indication is configured to be a fourth indication, the fourth indication being configured to request subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered, and

- the another indication is configured to be a sixth indication, the sixth indication being configured to indicate the third information configured to be requested.

49. The second node (112, 131) according to claim 48, wherein the third information is configured to indicate at least one of: i. a second identifier of the second event configured to be requested; ii. one or more applications; and iii. an identifier of the first device (131).

50. The second node (112, 114, 115, 131) according to any of claims 43-49, wherein the first node (111) is configured to be a Network Data Analytics Function, NWDAF, and the second node (112) is configured to be one of: a User Plane Function, UPF, and a Unified Data Repository, UDR.

51. The second node (112, 114, 115, 131) according to any of claims 43-49, wherein the first node (111) is configured to be a Network Data Analytics Function, NWDAF and the first second node (114) is configured to be a Unified Data Repository, UDR.

52. The second node (112, 114, 115, 131) according to any of claims 43-49, wherein the first node (111) is a Network Data Analytics Function, NWDAF and the second second node (115) is configured to be a User Plane Function, UPF.

53. A communications system (100), for handling tethering, the communications system (100) comprising a first node (111) and a one or more second nodes (112), the communications system (100) being configured to:

- receive, by the one or more second nodes (112), an indication from the first node (111), the indication being configured to request subscription to an event to receive information indicative of whether or not the one or more devices (130) configured to operate in the communications system (100) are being tethered,

- send, by the one or more second nodes (112), in response to the received indication, another indication, the another indication being configured to indicate the information configured to be requested, - determine, by the first node (111), whether or not the one or more devices (130) are being tethered, the determining being configured to be based on: i. the information configured to be gathered by the first node (111) from the one or more second nodes (112), the information being configured to be indicative of tethered traffic in the communications system (100), and ii. a predictive model of tethering behavior, and

- initiate providing, the first node (111) a result of the determination to a third node (113) configured to operate in the communications system (100).

54. The communications system (100) according to claim 53, wherein the predictive model is configured to be a machine-learning model, and wherein the communications system (100) is further configured to:

- train, by one of the first node (111) or another node (117) configured to operate in the communications system (100), the machine-learning model based on at least a first subset of one or more of: the first information, the second information, and the third information, and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be based on the machine learning model configured to be trained.

55. The communications system (100) according to any of claims 53-54, the communications system (100) being further configured to:

- receive, by the first node (111), a first indication from the third node (113), the first indication being configured to request to receive one or more analytics on whether or not the one or more of devices (130) are being tethered, the first indication being configured to indicate: i. one or more applications; and ii. one or more identifiers of the one or more devices (130); and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be triggered by the first indication configured to be received.

56. The communications system (100) according to any of claims 53-55, the communications system (100) being further configured to at least one of:

- send, by the first node (111), a second indication to a first second node (114) of the one or more second nodes (112), the second indication being configured to request subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered, - send, by the first node (111), a third indication to a second second node (115) of the one or more second nodes (112), the third indication being configured to request subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- send, by the first node (111), a fourth indication to a third second node, the third second node being configured to be a first device (131) of the one or more devices 130), the fourth indication being configured to request subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered.

57. The communications system (100) according to claims 55 and 56, wherein the sending of at least one of the second indication, the third indication and the fourth indication is configured to be triggered by the receiving of the first indication.

58. The communications system (100) according to claim 53-57, wherein the second node (112) is configured to be a first second node (114), and wherein:

- in the receiving by the second node (112), the received indication is configured to be a second indication, the second indication being configured to request subscription to receive first information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- in the sending by the second node (112), the another indication is configured to be a fifth indication, the fifth indication being configured to indicate the first information configured to be requested, and wherein the communications system (100) is further configured to:

- receive, by the first node (111), in response to the second indication configured to be sent, a fifth indication from the first second node (114), the fifth indication being configured to indicate the first information configured to be requested, and wherein the determining of whether or not the one or more of devices (130) are being tethered by the one or more second devices (140) is configured to be based on the fifth indication configured to be received.

59. The communications system (100) according to claim 58, wherein the first information is configured to indicate historic tethering information of the one or more devices (130), and wherein the first information is configured to indicate at least the one or more identifiers of the one or more devices (130). 60. The communications system (100) according to any of claims 53-59, wherein the second node (112) is configured to be a second second node (115), and wherein:

- in the receiving by the second node (112), the indication configured to be received is configured to be a third indication, the third indication being configured to request subscription to a first event to receive second information of the information indicative of whether or not the one or more of devices (130) are being tethered, and

- in the sending by the second node (112), the another indication is configured to be a seventh indication, the seventh indication being configured to indicate the second information configured to be requested, and wherein the communications system (100) is further configured to:

- receiving, by the first node (111), in response to the third indication configured to be sent, a seventh indication from the second second node (115), the seventh indication being configured to indicate the second information configured to be requested, and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be based on the seventh indication configured to be received.

61. The communications system (100) according to claim 60, wherein the second information is configured to indicate at least one of: i. a first identifier of the first event configured to be requested; ii. protocol metrics; iii. one or more applications; and iv. one or more identifiers of the one or more devices (130).

62. The communications system (100) according to any of claims 53-61, wherein the second node (112) is configured to be a third second node, wherein the third second node is configured to be a first device (131) of the one or more devices (130), and wherein:

- in the receiving by the second node (112), the indication configured to be received is configured to be a fourth indication, the fourth indication being configured to request subscription to a second event to receive third information indicative of whether or not the first device (131) is being tethered, and

- in the sending by the second node (112), the another indication is configured to be a sixth indication, the sixth indication being configured to indicate the third information configured to be requested, and wherein the communications system (100) is further configured to:

- receive, by the first node (111), in response to the fourth indication configured to be sent, a sixth indication from the first device (131), the sixth indication being configured to indicate the third information configured to be requested, and wherein the determining of whether or not the one or more of devices (130) are being tethered is configured to be based on the sixth indication configured to be received. 63. The communications system (100) according to claim 62, wherein the third information is configured to indicate at least one of: i. a second identifier of the second event configured to be requested; ii. one or more applications; and iii. an identifier of the first device (131).

64. The communications system (100) according to any of claims 53-63, wherein the first node (111) is configured to be a Network Data Analytics Function, NWDAF, the third node (113), is configured to be a Policy Charging Function, PCF, or an Operation Administration and Maintenance, OAM, and the one or more second nodes (112) are configured to be at least one of: a User Plane Function, UPF, and a Unified Data

Repository, UDR.