[go: up one dir, main page]

WO2023274569A1 - Obtention d'informations relatives à des événements de fonction modem - Google Patents

Obtention d'informations relatives à des événements de fonction modem Download PDF

Info

Publication number
WO2023274569A1
WO2023274569A1 PCT/EP2021/076130 EP2021076130W WO2023274569A1 WO 2023274569 A1 WO2023274569 A1 WO 2023274569A1 EP 2021076130 W EP2021076130 W EP 2021076130W WO 2023274569 A1 WO2023274569 A1 WO 2023274569A1
Authority
WO
WIPO (PCT)
Prior art keywords
tethering
session
traffic
policy
network function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2021/076130
Other languages
English (en)
Inventor
Antonio INIESTA GONZALEZ
Miguel Angel MUÑOZ DE LA TORRE ALONSO
Irene Martin Cabello
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to US18/570,285 priority Critical patent/US20250132938A1/en
Publication of WO2023274569A1 publication Critical patent/WO2023274569A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H04L12/1407—Policy-and-charging control [PCC] architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1485—Tariff-related aspects
    • H04L12/1489—Tariff-related aspects dependent on congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80—Rating or billing plans; Tariff determination aspects
    • H04M15/8027—Rating or billing plans; Tariff determination aspects based on network load situation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8228—Session based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8271—Based on the number of used services, e.g. call forwarding or call barring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/93—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP using near field or similar technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing

Definitions

  • Embodiments described herein relate to methods and apparatuses for obtaining information relating to tethering events.
  • Figure 1 illustrates a 5G reference architecture as defined by 3GPP.
  • PCF Policy Control Function
  • SMF Session Management Function
  • UPF User Plane Function
  • PCF Policy Control Function
  • PCC Policy and Charging Control
  • PCEF Policy and Charging Enforcement Function
  • the Session Management function supports different functionalities, for example, the SMF may receive PCC rules from the PCF and may configure the UPF accordingly through the N4 reference point as follows: -
  • the SMF may control the packet processing in the UPF by establishing, modifying or deleting PFCP Sessions and by provisioning (that is, adding, modifying or deleting) Packet Detection Rule (PDRs), Forwarding Action rule (FARs), Usage Reporting Rule (URRs), QoS Enforcement Rule (QERs) and/or Buffering Action Rules (BARs) per Packet Forwarding Control Protocol (PFCP) session, whereby a PFCP session may correspond to an individual Protocol Data Unit (PDU) session or a standalone PFCP session not tied to any PDU session.
  • PDRs Packet Detection Rule
  • FARs Forwarding Action rule
  • URRs Usage Reporting Rule
  • QERs QoS Enforcement Rule
  • BARs Buffering Action Rules
  • Each PDR contains Packet Detection Information (PDI) specifying the traffic filters or signatures against which incoming packets are matched.
  • PDI Packet Detection Information
  • Each PDR is associated to the following rules which provide the set of instructions to apply to packets matching the PDI: one FAR, which contains instructions related to the processing of the packets, specifically forward, duplicate, drop or buffer the packet with or without notifying the Control Plane (CP) function about the arrival of a Downlink (DL) packet; zero, one or more QERs, which contain instructions related to the Quality of Service
  • QoS Quality of service
  • URRs which contain instructions related to traffic measurement and reporting
  • BARs which contain the buffering rules to apply to the matching packets.
  • the User Plane function supports handling of user plane traffic based on the rules received from the SMF, for example, packet inspection (through PDRs) and different enforcement actions, such as traffic steering, Quality of Service (QoS) enforcement, and charging and/or reporting (through FARs, QERs, URRs, BARs).
  • Tethering is the practice of using a mobile device as a hotspot to connect to the Internet on another device, such a laptop or another mobile phone.
  • Many mobile operating system versions offer tethered internet access capabilities. Mobile network operators are interested in the detection of tethering events, in order to then apply different policies (such as access control policies, charging and/or reporting policies, and QoS enforcement policies, for example), to tethering traffic.
  • tethering traffic may consume a significant bandwidth that the mobile network infrastructure is not dimensioned for.
  • tethering traffic may not be currently charged any extra for in the case of flat tariff subscriptions.
  • an operator may potentially require one of the following: the enablement and/or disablement of tethering for a PDU session over the N4 interface, a restriction or limitation of the amount of tethering, (for example, by limiting the number of tethered devices and/or limiting the UL/DL bitrate when tethering is detected), the provision of separate QoS control policies for the traffic intended for a master device and traffic intended for the one or more tethered devices, and a change to a rating for an application ' s tethered traffic, and a request that the tethering is detected and reported tethering.
  • 3GPP has not specified tethering control, and tethering control has instead been left up to proprietary implementations.
  • a method performed at a first network function for obtaining information relating to tethering events comprises receiving, from a second network function, a first request to report information either related to detected tethering events in a session or related to detected tethering events for one or more services in a session; detecting a first tethering event at a first device; and transmitting a first message to the second network function, the first message comprising tethering information related to the first tethering event.
  • a method performed at a third network function for obtaining information relating to tethering events comprises obtaining first information for use in determining policies to be applied to traffic; determining, based on the first information, a first policy to be applied to either tethering traffic in a session or tethering traffic for one or more services in the session, wherein the first policy indicates that a second network function should report information relating either to detected tethering events in the session or to detected tethering events for the one or more services in the session; and transmitting to a second network function a first request to report information related either to detected tethering events in the session or to detected tethering events for the one or more services in the session.
  • a method performed at a second network function for obtaining information relating to tethering events.
  • the method comprises transmitting, to a first network function, a first request to report information related to either detected tethering events in a session or detected tethering events for one or more services in the session; and receiving a first message from the first network function, the first message comprising tethering information related to either a first tethering event in the session at a first device or a first tethering event for one of the one or more services in the session at a first device.
  • a method performed in a fourth network function for providing first information for use in determining policies relating to tethering events.
  • the method comprises: transmitting, to a third network function, policy information relating at least in part to tethering events, wherein the policy information comprises one or more of: an identification of one or more services to which a first part of the policy information applies; an indication as to whether tethering is allowed for the session or allowed for the one or more services; a maximum number of devices allowed to tether for the session or allowed to tether for the one or more services; a list of device types allowed to tether for the session or allowed to tether for the one or more services.
  • a method performed at a third network function for obtaining information relating to tethering events comprises obtaining first information for use in determining policies to be applied to traffic; determining, based on the first information, a first policy to be applied to traffic of a session; and transmitting, to a second network function, a rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • a method performed at a first network function for applying a rule to tethering traffic comprises receiving, from a second network function, a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • a method performed at a second network function for applying a rule to tethering traffic comprises transmitting to a first network function a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • a first network function for obtaining information relating to tethering events.
  • the first network function comprises processing circuitry configured to: receive, from a second network function, a first request to report information either related to detected tethering events in a session or related to detected tethering events for one or more services in a session; detect a first tethering event at a first device; and transmit a first message to the second network function, the first message comprising tethering information related to the first tethering event.
  • a third network function for obtaining information relating to tethering events.
  • the third network function comprises processing circuitry configured to: obtain first information for use in determining policies to be applied to traffic; determine, based on the first information, a first policy to be applied to either tethering traffic in a session or tethering traffic for one or more services in the session, wherein the first policy indicates that a second network function should report information relating either to detected tethering events in the session or to detected tethering events for the one or more services in the session; and transmit to a second network function a first request to report information related either to detected tethering events in the session or to detected tethering events for the one or more services in the session.
  • a second network function for obtaining information relating to tethering events.
  • the second network function comprises processing circuitry configured to: transmit, to a first network function, a first request to report information related to either detected tethering events in a session or detected tethering events for one or more services in the session; and receive a first message from the first network function, the first message comprising tethering information related to either a first tethering event in the session at a first device or a first tethering event for one of the one or more services in the session at a first device.
  • a fourth network function for providing first information for use in determining policies relating to tethering events.
  • the fourth network function comprises processing circuitry configured to: transmit, to a third network function, policy information relating at least in part to tethering events, wherein the policy information comprises one or more of: an identification of one or more services to which a first part of the policy information applies; an indication as to whether tethering is allowed for the session or allowed for the one or more services; a maximum number of devices allowed to tether for the session or allowed to tether for the one or more services; a list of device types allowed to tether for the session or allowed to tether for the one or more services.
  • a third network function for applying a rule to tethering traffic.
  • the third network function comprises processing circuitry configured to obtain first information for use in determining policies to be applied to traffic; determine, based on the first information, a first policy to be applied to traffic of a session; and transmit, to a second network function, a rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • a first network function for applying a rule to tethering traffic.
  • the first network function comprises processing circuitry configured to: receive, from a second network function, a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non tethering traffic, wherein each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • a second network function for applying a rule to tethering traffic.
  • the second network function comprises processing circuitry configured to: transmit to a first network function a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non tethering traffic, wherein each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • Figure 1 illustrates a 5G reference architecture as defined by 3GPP
  • Figure 2 illustrates a method performed at a first network function for obtaining information relating to tethering events
  • Figure 3 illustrates a method performed at a third network function for obtaining information relating to tethering event
  • Figure 4 illustrates a method performed at a second network function for obtaining information relating to tethering events
  • Figure 5 illustrates a method performed in a fourth network function for providing first information for use in determining policies relating to tethering events
  • Figure 6 illustrates a further method performed at a third network function for obtaining information relating to tethering events
  • Figure 7 illustrates a further method performed at a first network function for obtaining information relating to tethering events
  • Figure 8 illustrates a sequence diagram illustrating an example implementation of the methods of Figures 2 to 5.
  • Figure 9 illustrates a sequence diagram illustrating an example implementation of the methods of Figures 1 , 3, 4 and 6.
  • Figure 10 illustrates a first network function comprising processing circuitry (or logic);
  • Figure 11 illustrates a third network function comprising processing circuitry (or logic);
  • Figure 12 and 17 illustrates a second network function comprising processing circuitry (or logic);
  • Figure 13 illustrates a fourth network function comprising processing circuitry (or logic);
  • Figure 14 illustrates another third network function comprising processing circuitry (or logic).
  • Figure 15 and 16 illustrates another first network function comprising processing circuitry (or logic).
  • Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • multiple PCC rules need to be installed by the PCF when different enforcements (for example, QoS, blocking traffic, charging) need to be applied for a service depending on whether the service is directly consumed by the UE handling the PDU session, or being tethered to a different device behind the UE. That is, two different application identifications (applds) have to be configured in order to provide two separate PCC rules for the same service depending on whether the service is tethered or not. Additionally, multiple PCC rules are currently required to enable different enforcement actions to be applied to each tethered device (behind the UE). For example, a first PCC rule would be required for a first tethering device 1 , and a second PCC rule would be required for a second tethering device.
  • differentiated treatment for example, different rating groups for Charging, different QoS handling, different access control
  • differentiated treatment for example, different rating groups for Charging, different QoS handling, different access control
  • enforcement actions for example, Access Control, Charging/Reporting, QoS
  • tethering policy could be either:
  • Differentiated Access Control for example, drop tethered traffic
  • the SMF will need to install the following URRs/FARs/QERs:
  • the SMF will need to install the following URRs/FARs/QERs: Differentiated Charging/Reporting, Access Control and QoS for the service ' s tethered traffic. In this case, the SMF will need to install the following URRs/FARs/QERs:
  • enforcement actions do not depend on the number of tethering devices. For example, for each service there could be different enforcement actions, for example blocking a first service tethered traffic while allowing a second service’s tethered traffic but with a low bandwidth.
  • Embodiments described herein propose methods and apparatuses that solve the above problems, for example, by utilizing an extended rule (corresponding to one or more services, or corresponding to a session) in order to provide dynamic enforcement actions for both the case in which the traffic is consumed by the master UE (e.g. traffic that is not tethered), and the case in which any other device behind the master UE is performing tethering (e.g. tethering traffic).
  • an extended rule corresponding to one or more services, or corresponding to a session
  • the embodiments described herein may be implemented, for example, by extending the N7 and N4 interfaces to enable the application of different enforcements to traffic consumed by tethering devices.
  • FIG. 1 illustrates a method 200 performed at a first network function for obtaining information relating to tethering events.
  • the first network function may be implemented in a first network node.
  • the first network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the first network function may comprise a UPF.
  • the first network function receives from a second network function, a first request to report information either related to detected tethering events in a session or related to detected tethering events for one or more services in a session. That is, the first network function may be requested to report information relating to any tethering traffic in a session (regardless of the service consumed), or to report information relating to tethering traffic that is consuming only specific services.
  • the second network function may be implemented in a second network node.
  • the second network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the second network function may comprise an SMF.
  • the first request may further comprise a request to establish or modify the session.
  • the first request may comprise a PCFP Session Establishment or Modification request (as will be described later with reference to Figures 8 and 9).
  • the request to establish or modify the session may be based on a first rule, wherein the first rule is to be applied to traffic either in the session or for the one or more services in the session.
  • the first rule may be based at least in part on a first policy to be applied either to tethering traffic in the session or to tethering traffic for the one or more services in the session.
  • the first policy may indicate that the second network function should report information relating either to detected tethering events in the session or to detected tethering events for the one or more services in the session.
  • the first policy may indicate that the second network function should report to the first network function when tethering events for the first service start and/or stop.
  • the first request may be transmitted separately from a request to establish or modify the session.
  • the first request may be transmitted as part of a newly defined tethering event message.
  • the first request may comprise a request to report one or more of: a device identification (for example, a devicelD) of any device either performing tethering events in the session or performing tethering events for the one or more services in the session; and a device type (for example, a laptop device, a smart 4K TV device) of any device either performing tethering events in the session or performing tethering events for the one or more services in the session.
  • a device identification for example, a devicelD
  • a device type for example, a laptop device, a smart 4K TV device
  • the first network function detects a first tethering event at a first device.
  • a first tethering event For example, it will be appreciated that an extension of the PFCP protocol (that is, an extension of the N4 interface) to create a new UPF capability related to tethering detection and enforcement may be negotiated between the SMF and the UPF.
  • the UPF features presently defined in 3GPP TS 29.244 may be extended as follows:
  • the first network function transmits a first message to the second network function, the first message comprising tethering information related to the first tethering event.
  • the tethering information may comprise one or more of: an indication that tethering has either been detected in the session or been detected for one of the one or more services in the session, an identification of the first device (for example, a devicelD); and an identification of a device type of the first device (for example, a laptop device, a smart 4K TV device).
  • the tethering information reported by the second network function may be dictated by what was requested in the first request.
  • the first rule may comprise a policy and charging control, PCC, rule or a session rule. It will be appreciated that a session rule may enable enforcements to be applied to traffic of a session independently of the service that is being consumed, whereas a PCC rule may specify enforcements that are to be applied to one or more services that are being consumed.
  • the method 200 may further comprise receiving, from the second network function, a second request to modify the session based on a second rule.
  • the second rule may comprise at least one tethering policy to be applied to tethering traffic of the first tethering event, and at least one traffic policy to be applied to either other non-tethering traffic in the session or other non-tethering traffic for one or more services in the session.
  • the second rule may comprise a PCC rule or a session rule.
  • this second request enables the first network function to apply the at least one tethering policy to tethering traffic of the first tethering event, and to apply the at least one traffic policy to either other non-tethering traffic in the session or other non-tethering traffic for one or more services in the session.
  • only one rule e.g. the second rule
  • the second rule may be formed based at least in part on the tethering information transmitted in step 206. How the second rule may be determined will now be described in greater detail with reference to the method 300 of Figure 3.
  • Figure 3 illustrates a method 300 performed at a third network function for obtaining information relating to tethering events.
  • the first network function may be implemented in a third network node.
  • the third network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the third network function may comprise a PCF.
  • the third network function obtains first information for use in determining policies to be applied to traffic.
  • at least part of the first information may be received from a fourth network function (for example, a UDR).
  • at least part of the first information may comprise extended subscription information received from the UDR.
  • existing session management subscription information may be extended such that it comprises information relating to tethering support per S- NSSAI/DNN.
  • this new information may be indicated by extending the existing data type “SmPolicyDnnData”, as currently defined in 3GPP TS 29.519, with a new attribute.
  • the data type “SmPolicyDnnData” presently defined in 3GPP TS 29.519 may be extended to define the following attribute:
  • the new attribute Tethering Information may be defined to comprise the following:
  • the at least part of the first information received from the fourth network function may comprise one or more of: an identification of the one or more services to which the at least part of the first information applies, an indication as to whether tethering is allowed for the session or for the one or more services, a maximum number of devices allowed to tether for the session or for the one or more services (for example, 3 devices), a list of device types allowed to tether for the session or for the one or more services (for example, a laptop device, a smart 4K device).
  • least part of the first information may comprise network operator policies.
  • a network operator may define that tethering traffic is always to be blocked for a particular type of service.
  • the third network function determines, based on the first information, a first policy to be applied to either tethering traffic in a session or tethering traffic for one or more services in the session.
  • the first policy may indicate that a second network function should report information relating either to detected tethering events in the session or to detected tethering events for the one or more services in the session.
  • the first policy may indicate that the second network function should report to the third network function when tethering events for the first service start and/or stop.
  • a currently defined rule such as a PCC rule or a session rule, may be extended to create the first rule such that the first rule further comprises an attribute that defines that a second network function should report information relating either to detected tethering events in the session or to detected tethering events for the one or more services in the session.
  • a PCC rule may be extended such that it comprises a “tetheringReporting” attribute.
  • This “tetheringReporting” attribute may indicate that the SMF is to detect and report tethered traffic associated with the PCC rule.
  • the “tetheringReporting” attribute may further indicate that an identifier of the device and/or an identifier of the type of device that is performing the tethering is to additionally be reported by the SMF.
  • the “tetheringReporting” attribute may be connected with the Application Detection and Control (ADC) feature.
  • ADC Application Detection and Control
  • the type PCC rule presently defined in 3GPP TS 29.512 may be extended to define the following attribute:
  • application detection may also be requested for the first service.
  • This request for application detection may be implemented using standard 3GPP mechanisms (for example, comprising a PCT APP_STA/APP_STO).
  • Application Detection Information IE within Usage Report IE presently defined in 3GPP TS 29.244 may be extended to define the following further information element (IE):
  • the Tethering Information IE within the Application Detection Information IE may be defined as follows:
  • the third network function transmits to a second network function a first request to report information related either to detected tethering events in the session or to detected tethering events for the one or more services in the session. That is, the second network function may be requested to report information relating to any tethering traffic in the session (regardless of the service consumed), or to report information relating to tethering traffic consuming only specific services.
  • the method 300 may further comprise the step of transmitting a first rule to a second network function, wherein the first rule is to be applied to either traffic of the session or traffic for one or more services in the session, and wherein the first rule is based at least in part on the first policy. It will be appreciated that the first rule may be a legacy rule, that is, to be applied to all traffic consumed by the UE, regardless whether the traffic is tethered or not tethered.
  • the first rule may comprise a policy and charging control, PCC, rule or a session rule.
  • the method 300 may further comprise the step of transmitting the first rule and the first request as part of a first message, wherein the first message comprises a response to a request to create or update the session.
  • the first request and first rule may be transmitted as part of a “Ncpf_SMPolicyControl_Create response” message.
  • the first request may comprise a request to report one or more of: a device identification (for example, a devicelD) of any device performing tethering events either in the session or for the one or more services in the session; and a device type of any device performing tethering events either in the session or for the one or more services in the session (for example, a laptop device, a smart 4K TV device).
  • a device identification for example, a devicelD
  • a device type of any device performing tethering events for example, a laptop device, a smart 4K TV device.
  • the method 300 may further comprise the step of receiving tethering information from the second network function related to a first tethering event at a first device, wherein the first tethering event is either in the session or for the one of the one or more services in the session.
  • the tethering information may be defined as described above with reference to Figure 2.
  • the first request may effectively therefore be passed from the third network function (e.g. PCF) to the second network function (SMF) and then on to the first network function (e.g. UPF).
  • the first rule e.g. a PCC rule
  • the tethering information may be passed from the first network function to the second network function and then on to the third network function.
  • the format of the first request, the first rule and the tethering may be modified at the second network function.
  • the format of the first request may be different in step 202 of Figure 2 and step 306 of Figure 3.
  • the format of the first rule may be different when transmitted from the third network function to the second network and when transmitted from the second network function to the first network function.
  • the format of the tethering information may be different when transmitted from the first network function to the second network and when transmitted from the second network function to the third network function.
  • the method 300 may further comprise the step of determining a second policy based on the tethering information and the first information, and updating the first rule, based on the second policy, to form a second rule, wherein the second rule comprises at least one tethering policy to be applied to tethering traffic of the first tethering event, and at least one traffic policy to be applied to other non tethering traffic in the session or other non-tethering traffic for the one or more services in the session.
  • the PCC rule may be extended such that it comprises one or more attributes that map to one of more policies to be applied to tethering traffic in the session.
  • the PCC rule may comprise one or more of the following attributes, “refQosTethData”, “refChgTethData”, “refllmTethData” and “refTcTethData”.
  • the data type PccRule as presently defined in 3GPP TS 29.512 may be extended to define the attributes “refQosTethData”, “refChgTethData”, “refllmTethData” and “refTcTethData” as follows:
  • Each of the attributes refQosTethData”, “refChgTethData”, “refUmTethData” and “refTcTethData” may map to one or more policies (e.g. defined by instances of “QoSdata”, “ChgData”, “TethData” and “UsageMonitoringData” respectively). That is, in some embodiments, the at least one tethering policy comprises one or more of: one or more traffic control policies to be applied to tethering traffic, one or more quality of service policies to be applied to tethering traffic, one or more charging policies to be applied to tethering traffic, and one or more usage monitoring policies to be applied to tethering traffic.
  • the at least one tethering policy may comprise a first traffic control policy, wherein the first traffic control policy comprises a policy to block at least some of the tethering traffic.
  • the tethering policy may indicate that the first service is to be blocked if the service is consumed for two or more devices behind the UE.
  • the one or more attributes that define each of one of more policies to be applied to tethering traffic in the session may further comprise one or more conditions, wherein the one or more conditions indicate that the relevant policy should only be applied to tethering traffic when the one or more conditions have been fulfilled.
  • an instance of “QosData” may comprise a condition that defines that the corresponding quality of service policy should only be applied to tethered traffic for devices that are of a certain device types. That is, the provision of a conditional attribute in such a manner may enable more granular enforcement to be applied to tethering traffic that is based on certain conditions.
  • an instance of data type “QosData” as presently defined in 3GPP TS 29.512 may be extended to define the following attributes to indicate that the relevant policy (as otherwise defined in the instance of “QoSData”) should only be applied to tethering traffic when one or more conditions have been fulfilled:
  • the data type “TrafficControlData” as presently defined in 3GPP TS 29.512 may be extended to define the following attributes to indicate that the relevant policy (as otherwise defined in the instance of “TrafficControlData”) should only be applied to tethering traffic when one or more conditions have been fulfilled:
  • the data type “ChargingData” as presently defined in 3GPP TS 29.512 may define the following attributes to indicate that the relevant policy (as otherwise defined in the instance of “Charging Data”) should only be applied to tethering traffic when one or more conditions have been fulfilled:
  • each of the at least one tethering policy to be applied to the tethering traffic may comprise one of more of: an identification of one or more devices to which the tethering policy is to be applied, an indication that the tethering policy is to be applied to all tethered traffic, a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session, and a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • a session rule may be extended in a similar manner to as described above to define one of more policies to be applied (potentially conditionally) to tethering traffic in the session. It will be appreciated that support of PCC and Session rule extensions may be negotiated between SMF and PCF, for example, with a new supported feature “Tethering”.
  • the method 300 may further comprise the step of transmitting the second rule to the second network function.
  • the formation of the second rule comprising at least one tethering policy to be applied to tethering traffic of the first tethering event, and at least one traffic policy to be applied to other non-tethering traffic in the session or other non-tethering traffic for the one or more services in the session, enables different enforcements to be applied to non-tethering and tethering traffic of the first service via the provision of a single rule.
  • the third network function may install a single rule for a first service that defines a first quality of service policy to be applied to non-tethering traffic, and a second quality of service policy to be applied to tethering traffic.
  • receipt of this information may enable the third network function (for example, the PCF) to request dynamically different enforcement to be applied to be applied to each different device performing tethering behind the UE.
  • the PCF may request an enforcement to be applied to the first device that is based on network operator policies specifically relating to devices of the device type.
  • network operator policies may depend one or more of: a number of devices tethering behind the first device, the types of devices tethering behind the first device, the time at which tethering is being performed, the location of the first device, the access type of the first device, and the RAT-type being used by the first device.
  • the provision of the tethering information and the first information to the third network function may enable the third network function to make dynamic policy decisions that are to be applied to tethering and non-tethering traffic in a session.
  • Figure 4 illustrates a method 400 performed at a second network function for obtaining information relating to tethering events.
  • the second network function may be implemented in a second network node.
  • the second network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the second network function may comprise a SMF.
  • the second network function transmits, to a first network function, a first request to report information related to either detected tethering events in a session or detected tethering events for one or more services in the session.
  • the second network function first receives, from the third network function, the first request to report information related to either detected tethering events for the session or detected tethering events for the one or more services in the session.
  • the format of the first request may be changed at the second network function.
  • the first request may be transmitted to the first network function as part of a PFCP Session Modification Request.
  • the first request may be received from the third network function as part of an Npcf_SMPolicyControl_Create response.
  • the first request may be defined as described above with reference to Figures 2 and 3.
  • the SMF may include, in an activation report of application traffic, extended information related to tethering.
  • the extended information may comprise information such as an identifier of the device performing the detected tethering and/or the type of the device performing the detected tethering.
  • the extended information be comprised in an “AppDetectionlnfo” attribute.
  • 29.512 may be extended to define the following attributes:
  • the “update URR IE” within a PFCP Session Modification Request as presently defined in 3GPP TS 29.244 may be extended as follows (extension indicated in bold type):
  • the “Create URR IE” within the PFCP Session Establishment Request as presently defined in 3GPP TS 29.244 may be extended as follows (extension indicated in bold type):
  • the first request may further comprise a request to establish or modify the session.
  • the first request may be transmitted separately from a request to establish or modify the session.
  • the method 400 further comprises further comprises receiving, from the third network function a first rule.
  • the first rule may be defined as described above with reference to Figures 2 and 3.
  • the step of applying the first rule to traffic in the session or to traffic for the one or more services in the session may comprise basing the request to establish or modify the session on the first rule.
  • the PFCP protocol may be extended with a new Tethering Rules IE in a Create/Modify PDR IE at the PFCP Session Establishment/Modification Request, in order to indicate the tethering policies on a per service basis.
  • the second network function receives a first message from the first network function, the first message comprising tethering information related to either a first tethering event in the session at a first device or a first tethering event for one of the one or more services in the session at a first device.
  • the tethering information may be defined as described above with reference to Figures 2 and 3 (e.g. in step 206 of Figure 2).
  • the method 400 further comprises transmitting the tethering information to a third network function.
  • the third network function may comprise a PCF, for example. This enables the third network function to form a second rule that is based at least in part on the transmitted tethering information, as described in greater detail with reference to Figure 3.
  • the method 400 further comprises further comprises receiving, from the third network function a second rule to apply to traffic for the session and applying the second rule either to traffic in the session or to traffic for the one or more services in the session.
  • the second rule may be defined as described above with reference to Figure 3.
  • the second rule enables different enforcements to be applied to non-tethering and tethering traffic of the first service.
  • the second rule may indicate that, for a first service, a first quality of service policy is to be applied to non-tethering traffic, and a second quality of service policy is to be applied to tethering traffic.
  • the step of applying the second rule may comprise transmitting, to the first network function, a third request to modify the session based on the second rule.
  • Figure 5 illustrates a method 500 performed at a fourth network function for providing first information for use in determining policies relating to tethering events.
  • the fourth network function may be implemented in a fourth network node.
  • the fourth network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment
  • the fourth network function may comprise a UPF.
  • the fourth network function transmits, to a third network function, policy information relating at least in part to tethering events, wherein the policy information comprises one or more of: an identification (for example, an appID) of one or more services to which a first part of the policy information applies, an indication as to whether tethering is allowed for the session or allowed for the one or more services, a maximum number of devices allowed to tether for the session or allowed to tether for the one or more services, and a list of device types (for example, a laptop device, a smart TV 4K device) allowed to tether for the session or allowed to tether for the one or more services.
  • an identification for example, an appID
  • a maximum number of devices allowed to tether for the session or allowed to tether for the one or more services for example, a laptop device, a smart TV 4K device
  • the method 400 as described with reference to Figure 4 may comprise, responsive to receiving the first message, applying a second rule to traffic for the session, wherein the second rule comprises at least one tethering policy to be applied to the tethering traffic for the first tethering event, and at least one traffic policy to be applied to either other non-tethering traffic in the session or other non-tethering traffic for the one or more services in the session. That is, in these embodiments, the third network function does not need to provide an updated rule to the second network function, wherein the update would have been based on the tethering information that has not (in this embodiment) been forwarded to the third network function.
  • the at least one tethering policy in the second rule may be defined as described above with reference to figures 2 and 3.
  • the method 400 may further comprise receiving the second rule from a third network function.
  • the second network function may receive only the second rule from the third network function. Therefore the only rule transmitted to the second network function may comprise at least one tethering policy to be applied to the tethering traffic for the first tethering event, and at least one traffic policy to be applied to either other non-tethering traffic in the session or other non-tethering traffic for the one or more services in the session.
  • the second network function may provide two different rules to the first network function.
  • the second network function may assume that no tethering traffic is occurring, and may first transmit a first rule to the third network function, wherein the first rule is based on the traffic policy as defined in the second rule received from the third network function.
  • the second network function may transmit a second rule to the first network function , where the second rule comprises the at least one tethering policy to be applied to the tethering traffic for the first tethering event as received in the second rule from the third network function.
  • Figure 6 illustrates a further method 600 performed at a third network function for obtaining information relating to tethering events.
  • the third network function may be implemented in a third network node.
  • the third network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the third network function may comprise a PCF.
  • the method 600 may be utilized in examples in which there is no need to apply enforcements to the tethering traffic of a session that are dependent on dynamic conditions.
  • the third network function obtains first information for use in determining policies to be applied to traffic.
  • at least part of the first information may be received from a fourth network function.
  • the third network function determines, based on the first information, a first policy to be applied to traffic of a session.
  • the third network function transmits, to a second network function, a rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • the at least one tethering policy may be defined as described above with reference to Figures 2 to 4.
  • the rule may comprise a policy and charging control, PCC, rule or a session rule.
  • Figure 7 illustrates a method performed at a first network function for applying a rule to tethering traffic.
  • the first network function may be implemented in a first network node.
  • the first network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the first network function may comprise a UPF.
  • the method 700 may be utilized in examples in which there is no need to apply enforcements to the tethering traffic of a session that are dependent on dynamic conditions.
  • the first network function receives, from a second network function, a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic.
  • Each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; and a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • this step enables the first network function to apply the at least one tethering policy to tethering traffic, and to apply the at least one traffic policy to either other non-tethering traffic.
  • the at least one tethering policy to be applied to tethering traffic may be applied to tethering traffic either in the session or for the one or more services in the session, and the at least one traffic policy to be applied to other non-tethering traffic may be applied to non-tethering traffic either in the session or for the one or more services in the session.
  • the rule may comprise a policy and charging control, PCC, rule or a session rule.
  • Figure 8 illustrates a method, in a second network function for applying a rule to tethering traffic.
  • the second network function may be implemented in a second network node.
  • the second network node may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.
  • the second network function may comprise a SMF.
  • the method 800 may be utilized in examples in which there is no need to apply enforcements to the tethering traffic of a session that are dependent on dynamic conditions.
  • the second network function transmits, to the first network function, a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic.
  • Each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; and a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • Figure 9 is a sequence diagram illustrating an example implementation of the methods of Figures 2 to 5.
  • This sequence diagram illustrates how different charging may be dynamically applied by a PCF for traffic for a first service, depending on whether the traffic is consumed directly by a UE (in which case, RatingGroupl is to be applied), by a laptop device tethering behind the UE (in which case, RatingGroup2 is to be applied), or by a 4K smart TV tethering behind the UE (in which case, RatingGroup3 is to be applied).
  • RatingGroupl a UE
  • RatingGroup2 tethering behind the UE
  • RatingGroup3 4K smart TV tethering behind the UE
  • tethering policy data is provisioned in the UDR as subscriber policy data, and as network operator policies configured in PCF. Additionally, the PDU session establishment new supported feature “tethering” (as described above) may have been negotiated between PCF and SMF.
  • policies associated to the first service are configured in PCF. These policies select the charging to apply when tethering is detected are based on the time, the number of devices tethering behind the UE, and device type of the device performing the detected tethering.
  • the existing mechanism may be extended to report UPF capabilities with a new capability (Tethering detection and enforcement). It will be appreciated that this would allow SMF to know which UPFs support this capability, and may influence UPF selection.
  • the SMF transmits a request for the establishment of a PDU session for a UE for a given Single Network Slice Selection Assistance Information (S-NSSAI)/ Data Network Name (DNN), to the PCF.
  • S-NSSAI Single Network Slice Selection Assistance Information
  • DNN Data Network Name
  • the PCF transmits, to the UDR, a request to obtain policy information relating at least in part to tethering events. It will be appreciated that the obtained policy information may form at least part of obtained first information for use in determining policies to be applied to traffic.
  • the policy information comprises session management policy data
  • this session management policy data comprises tethering subscription data.
  • the tethering subscription data may relate to the NSSAI/DNN combination and/or relate to one or more services.
  • the tethering subscription data may also comprise information relating to a maximum number of devices that are permitted to tether (behind the UE) and/or types of devices that are permitted to tether (behind the UE).
  • at least part of the first information may be based on a network operator policy configured in the PCF.
  • a network operator policy has been configured in PCF to provide different rating groups for the first service that depends on the type of device executing the first service, and the time at which the execution occurs.
  • the UDR transmits, to the PCF, the policy information relating at least in part to tethering events.
  • the UDR executes step 903 by transmitting a Nudr DataRepository Query response message to the PCF.
  • the Nudr DataRepository Query response message may comprise the “Tethering” attribute as defined above.
  • the PCF obtains (part of) the first information for use in determining policies to be applied to traffic.
  • the PCF makes a policy decision and determines to install a first PCC rule.
  • the installed first PCC rule determines that a certain Rating Group (RG1 ) should be applied to the traffic that is consumed for the first service.
  • RG1 Rating Group
  • this first PCC rule is a legacy rule that is to be applied to all traffic that is consumed by the UE for the first service, regardless of whether that traffic is tethered or not.
  • the PCF may be considered to assume that, as there is not yet any indication of tethering occurring at the UE, the policy may be focused on tethering traffic, and may be updated as and when tethering traffic is detected.
  • the PCF activates an application traffic reporting notification, such that when tethering that is being performed at the UE for the first service, the tethering is reported.
  • This may be executed extending the PCC rule to include the “tetheringReporting” attribute (as defined above). Additionally, the PCC rule may include the PCT event triggers APP STA and APP STO for the PDU session.
  • the PCF transmits to the SMF a first request to report information related to detected tethering events for the first service in the session.
  • Step 805 corresponds to step 306 of Figure 3.
  • the PCF transmits the first PCC rule to the SMF.
  • the first PCC rule and the first request are transmitted as part of a first message, wherein the first message comprises a response to a request to create or update the session.
  • the PCF executes the first message by transmitting a Npcf_SMPolicyControl_Create response message to the SMF.
  • the Npcf_SMPolicyControl_Create response message comprises the first PCC rule, wherein the first PCC rule comprises the “tetheringReporting” attribute (as defined above), and the “appld” identifying the first service.
  • the Npcf_SMPolicyControl_Create response message may additionally or alternatively comprise a session rule, which may indicate that the defined enforcements are to be applied to the traffic regardless of the service being consumed.
  • the SMF transmits a first request to report information related to detected tethering events for the first service in the session, to the UPF.
  • Step 906 corresponds to step 402 in Figure 4.
  • the SMF executes this by transmitting a PFCP Session Establishment/Modification Request message to the UPF.
  • the PFCP Session Establishment/Modification Request message further comprises the first PCC rule.
  • the first PCC rule is transmitted in the format of the relevant PDRs/FARs/QERs/URRs to be applied to the traffic.
  • the PFCP Session Establishment/Modification Request message comprises a PDR (e.g. PDR1 ) with PDI of type application with appld that identifies the first service, and a FAR, a QER and a URR that correspond to PDR1 (for example, FAR1 , QER1 and URR1 ) that are based on the received first PCC rule.
  • PDR e.g. PDR1
  • FAR e.g. PDR1
  • QER QER
  • URR a URR that correspond to PDR1 (for example, FAR1 , QER1 and URR1 ) that are based on the received first PCC rule.
  • the PFCP protocol has been extended by extending the application start event to include a request for the UPF to report to the SMF when tethering is detected.
  • a new tethering event message may be defined separately that comprises a request for the UPF to report to the SMF when tethering is detected. It will be appreciated that such a tethering event message may further comprise tethering related information as defined above for the application start event.
  • the UPF detects a first tethering event at a first device for the first service.
  • Step 807 corresponds to step 204 of Figure 2.
  • the UPF may use TCP Options (for example, timestamp) to identify the tethering device.
  • the device that is performing the tethering behind the UE is a laptop device.
  • the UPF transmits a first message to the SMF, wherein the first message comprises tethering information related to the first tethering event. That is, the UPF reports information related to detected tethering events for the first service in the session to the SMF.
  • Step 808 corresponds to step 206 of Figure 2 and step 404 of Figure 4.
  • the UPF informs the SMF that a tethering event has been detected for the first service by transmitting a PFPC Session Report Request message to the SMF.
  • This PFPC Session Report Request message comprises the appld of the first service, and tethering information relating to the detected tethering event, including an identifier of the device (device_1 ) performing the tethering and the type of detected device (a laptop device).
  • the SMF transmits the tethering information to the PCF. That is, upon reception of a notification that a tethering event has been detected for the first service, SMF forwards this notification to the PCF. In this illustrated embodiment, the SMF executes this by transmitting a Npcf_SMPolicyControl_Update request to the PCF.
  • the Npcf_SMPolicyControl_Update request comprises the appld of the first service, and tethering information relating to the detected tethering event, including an identifier of the device (device_1 ) performing the tethering and the type of detected device (a laptop device).
  • the PCF determines a second policy based on the received tethering information and the first information, and updates the first PCC rule, based on the second policy, to form a second PCC rule, wherein the second PCC rule comprises at least one tethering policy to be applied to tethering traffic of the first tethering event, and at least one traffic policy to be applied to other non-tethering traffic in the session or other non-tethering traffic for the one or more services in the session.
  • the PCF makes a policy decision based on the number of devices presently tethering (which may be determined based on the received tethering information), the device type of the first device and the time, and determines to apply a different rating group (RG2) to the first device.
  • the PCF transmits the second PCC rule to the SMF.
  • this is executed by transmitting a Npcf_SMPolicyControl_Update response message to the SMF.
  • the pcf_SMPolicyControl_Update response message comprises the second PCC rule comprising the ““refChgTethData” attribute as defined above.
  • the SMF reads the updated information in the second PCC rule, and determines to apply a different policy (in this case, applying Rating Group 2) for the tethered traffic of the first device based on the updated information.
  • a different policy in this case, applying Rating Group 2
  • the SMF applies the second PCC rule to traffic for the session .
  • this is executed by transmitting a PFCP Session Modification Request message to the UPF.
  • the PFCP Session Modification Request message comprises the deviceld of the first device, and the policy that is to be applied to the tethered traffic from the first device.
  • the PFCP Session Modification Request message comprises relevant PDRs/FARs/QERs/URRs to be applied to the tethered traffic of the first device that are based on the second rule.
  • the UPF detects a second tethering event at a second device for the first service.
  • the UPF may use TCP Options (for example, timestamp) to identify the second device.
  • the second device that is performing the tethering behind the UE is a smart 4K TV device.
  • the UPF transmits a second message to the SMF, wherein the second message comprises tethering information related to the second tethering event.
  • the UPF informs the SMF that a second tethering event has been detected for the first service by transmitting a PFPC Session Report Request message to the SMF.
  • This PFPC Session Report Request message comprises the appld of the first service, and tethering information relating to the second tethering event, including an identifier of the device (device_2) doing tethering and the type of detected device (a smart 4K TV device).
  • the SMF transmits the tethering information to the PCF. That is, upon reception of a notification that a tethering event has been detected for the first service, SMF forwards this notification to the PCF. In this illustrated embodiment, the SMF executes this by transmitting a Npcf_SMPolicyControl_Update request to the PCF.
  • the Npcf_SMPolicyControl_Update request comprises the appld of the first service, and tethering information relating to the detected second tethering event, including an identifier of the device (device_2) doing tethering and the type of detected device (a smart 4K tv device).
  • the PCF determines a third policy based on the further received tethering information and the first information, and updates the second PCC rule, based on the third policy, to form a third PCC rule, wherein the third PCC rule comprises at least one tethering policy to be applied to tethering traffic of the first tethering event, and at least one traffic policy to be applied to other non-tethering traffic in the session or other non-tethering traffic for the one or more services in the session.
  • the PCF transmits the third PCC rule to the SMF. In this illustrated embodiment, this is executed by transmitting a Npcf_SMPolicyControl_Update response message to the SMF. In this example, the Npcf_SMPolicyControl_Update response message comprises the third PCC rule.
  • the SMF reads the updated information in the third PCC rule, and determines to apply Rating Group 3 to the tethered traffic of the second device, for the first service.
  • the SMF applies the third PCC rule to traffic for the session.
  • this is executed by transmitting a PFCP Session Modification Request message to the UPF.
  • the PFCP Session Modification Request message comprises the deviceld of the second device, and the policy that is to be applied to the tethered traffic from the second device, for the first service.
  • the PFCP Session Modification Request message comprises relevant PDRs/FARs/QERs/URRs to be applied to the tethered traffic of the second device for the first service that are based on the third rule.
  • Figure 10 is a sequence diagram illustrating an example implementation of the methods of Figures 2,4, 5 and 6.
  • the PCF will therefore not require (from the SMF) notifications relating to tethered traffic for a first service, which may include information relating to device type, or a device identifier, for example.
  • the PCF may decide at PDU session establishment (or when appropriate) to install the aforementioned tethering extensions in the PCC rules.
  • These tethering extensions comprise the different enforcements that the SMF is to apply to tethered and non- tethered traffic.
  • the tethering extensions may additionally comprise conditions that are to be fulfilled in order for the enforcements to be applied (such as device type and a total number of devices tethering, for example).
  • the SMF then applies the tethering extension to the PCC rule dynamically (i.e. it requests to be notified of tethering events, and applies tetering policies based on the PCC rule received from the PCF dynamically). It will however, be appreciated that in some circumstances the SMF may also apply a PCC rule statically (i.e. without requiring any notification of tethering events from the UPF).
  • tethering policy data is provisioned in UDR as subscriber policy data, and as network operator policies configured in PCF. Additionally, the PDU session establishment new supported feature “tethering” (as described above) may have been negotiated between PCF and SMF.
  • policies associated to the first service are configured in PCF. These policies select the charging to apply when tethering is detected are based on the time, the number of devices tethering behind the UE, and device type of the device performing the detected tethering.
  • the existing mechanism may be extended to report UPF capabilities with a new capability (Tethering detection and enforcement). It will be appreciated that this would allow SMF to know which UPFs support this capability, and may influence UPF selection.
  • the SMF transmits a request for the establishment of a PDU session for a UE for a given S-NSSAI/DNN to the PCF.
  • the PCF transmits, to the UDR, a request to obtain policy information relating at least in part to tethering events. It will be appreciated that the obtained policy information may form at least part of obtained first information for use in determining policies to be applied to traffic.
  • the policy information comprises session management policy data, wherein the session management policy data comprises tethering subscription data.
  • the tethering subscription data may relate to the NSSAI/DNN combination and/or relate to one or more services. It will also be appreciated that the tethering subscription data may also comprise information relating to a maximum number of devices that are permitted to tether (behind the UE) and/or the types of devices that are permitted to tether (behind the UE).
  • At least part of the first information may be based on a network operator policy configured in the PCF.
  • a network operator policy has been configured in PCF to provide different rating groups for the first service that depend on the type of device executing the first service, and the time at which this execution occurs.
  • the UDR transmits, to the PCF, policy information relating at least in part to tethering events.
  • the UDR executes step 1003 by transmitting a Nudr DataRepository Query response message to the PCF.
  • the Nudr DataRepository Query response message may comprise the “Tethering” attribute as defined above.
  • Step 1003 the PCF obtains (at least part of) the first information for use in determining policies to be applied to traffic.
  • Step 1003 corresponds to step 603 of Figure 6.
  • the PCF makes a policy decision and determines to install a single PCC rule.
  • the installed PCC rule indicates that a certain Rating Group (RG_10) should be applied to the traffic consumed by laptop devices tethering behind the UE, for the first service.
  • the installed PCC rule also indicates that another Rating Group (RG_11) should be applied to the traffic consumed by smart TV devices tethering behind the UE, when less than 3 devices are tethering behind the UE.
  • Step 1004 the PCF determines, based on the first information, a first policy to be applied to traffic of a session. Step 1004 corresponds to step 604 of Figure 6.
  • the PCF transmits, to the SMF, a rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • Step 1005 corresponds to step 606 of Figure 6.
  • the PCF executes this by transmitting a Npcf_SMPolicyControl_Create response message to the SMF.
  • the Npcf_SMPolicyControl_Create response message comprises a PCC rule, wherein the PCC rule comprises the “refChgTethData”, which points to the two aforementioned different instances of “ChargingData”, and the “appld” identifying the first service.
  • the Npcf_SMPolicyControl_Create response message may additionally or alternatively comprise a session rule, which may indicate enforcements that are to be applied to the traffic regardless of the service being consumed.
  • the SMF transmits a first request to report information related to detected tethering events the first service in the session to the UPF.
  • the SMF executes this by transmitting a PFCP Session Establishment/Modification Request message to the UPF.
  • Step 1006 corresponds to step 402 of Figure 4.
  • the PFCP Session Establishment/Modification Request message comprises relevant PDRs/FARs/QERs/URRs to be applied to the traffic that are based on the rule.
  • these PDRs/FARs/QERs/URRs may be based on the traffic policy to be applied to other non-tethering traffic.
  • the PFCP Session Establishment/Modification Request message will comprises a PDR (e.g. PDR1 ) with PDI of type application with appld that identifies the first service, and a FAR, a QER and a URR that correspond to PDR1 (for example, FAR1 , QER1 and URR1 ) that are based on the rule.
  • PDR e.g. PDR1
  • FAR e.g. PDR1
  • QER a QER and a URR that correspond to PDR1 (for example, FAR1 , QER1 and URR1 ) that are based on the rule.
  • the PFCP protocol has been extended by extending the application start event to include a request for the UPF to report to the SMF when tethering is detected.
  • the UPF may report tethering related information to the SMF such as a number of devices that are performing tethering behind the UE, identifiers of these devices, and device type information for
  • a new tethering event message may be defined separately that comprises a request for the UPF to report to the SMF when tethering is detected. It will be appreciated that such a tethering event message may further comprise tethering related information as defined above for the application start event.
  • the UPF detects a first tethering event at a first device for the first service.
  • the UPF may use TCP Options (for example, timestamp) to identify the first device.
  • Step 1007 corresponds to step 204 in Figure 2.
  • the first device that is performing the tethering behind the UE is a laptop device.
  • the UPF transmits a first message to the SMF, wherein the first message comprises tethering information related to the first tethering event. That is, the UPF reports information related to detected tethering events for the first service in the session to the SMF.
  • Step 1008 corresponds to step 206 in Figure 2 and step 404 in Figure 4.
  • the UPF informs the SMF that a tethering event has been detected for the first service by transmitting a PFPC Session Report Request message to the SMF.
  • This PFPC Session Report Request message comprises the appld of the first service, and tethering information relating to the detected tethering event, including an identifier of the device (device_1) performing tethering and the type of detected device (a laptop device).
  • RG_10 Rating Group 10
  • the SMF applies the rule to traffic for the session, the rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • RG_10 Rating Group 10
  • the UPF detects a second tethering event at a second device for the first service.
  • the UPF may use TCP Options (for example, timestamp) to identify the second device.
  • the second device that is performing the tethering behind the UE is a smart 4K TV device.
  • the UPF transmits a second message to the SMF, wherein the second message comprises tethering information related to the second tethering event.
  • the UPF informs the SMF that a second tethering event has been detected for the first service by transmitting a PFPC Session Report Request message to the SMF.
  • This PFPC Session Report Request message comprises the appld of the first service, and tethering information relating to the detected second tethering event, including an identifier of the device (device_2) performing tethering and the type of detected device (a smart 4K TV device).
  • Rating Group 11 RG_11
  • the SMF applies the rule to traffic for the session, the rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • Figure 11 illustrates a first network function 1100 comprising processing circuitry (or logic) 1101.
  • the processing circuitry 1101 controls the operation of the first network function 1100 and can implement the method 200 described herein in relation to a first network function 1100.
  • the processing circuitry 1101 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first network function 1100 in the manner described herein.
  • the processing circuitry 1101 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 200 described herein in relation to the first network function.
  • the processing circuitry 1101 of the first network function 1100 is configured to: receive, from a second network function, a first request to report information either related to detected tethering events in a session or related to detected tethering events for one or more services in a session; detect a first tethering event at a first device; and transmit a first message to the second network function, the first message comprising tethering information related to the first tethering event.
  • the first network function 1100 may optionally comprise a communications interface 1102.
  • the communications interface 1102 of the first network function 1100 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1102 of the first network function 1100 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1101 of first network function 1100 may be configured to control the communications interface 1102 of the first network function 1100 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the first network function 1100 may comprise a memory 1103.
  • the memory 1103 of the first network function 1100 can be configured to store program code that can be executed by the processing circuitry 1101 of the first network function 1100 to perform the method 200 described herein in relation to the first NF 1100.
  • the memory 1103 of the first network function 1100 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1101 of the first network function 1100 may be configured to control the memory 1103 of the first network function 1100 to store any requests, resources, information, data, signals, or similar that are described herein.
  • Figure 12 illustrates a third network function 1200 comprising processing circuitry (or logic) 1201.
  • the processing circuitry 1201 controls the operation of the third network function 1200 and can implement the method 300 described herein in relation to a third network function 1200.
  • the processing circuitry 1201 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the third network function 1200 in the manner described herein.
  • the processing circuitry 1201 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 300 described herein in relation to the third network function.
  • the processing circuitry 1201 of the third network function 1200 is configured to: obtain first information for use in determining policies to be applied to traffic; determining, based on the first information, a first policy to be applied to either tethering traffic in a session or tethering traffic for one or more services in the session, wherein the first policy indicates that a second network function should report information relating either to detected tethering events in the session or to detected tethering events for the one or more services in the session; and transmit to a second network function a first request to report information related either to detected tethering events in the session or to detected tethering events for the one or more services in the session.
  • the third network function 1200 may optionally comprise a communications interface 1202.
  • the communications interface 1202 of the third network function 1200 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1202 of the third network function 1200 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1201 of third network function 1200 may be configured to control the communications interface 1202 of the third network function 1200 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the third network function 1200 may comprise a memory 1203.
  • the memory 1203 of the third network function 1200 can be configured to store program code that can be executed by the processing circuitry 1201 of the third network function 1200 to perform the method 300 described herein in relation to the third network function 1200.
  • the memory 1203 of the third network function 1200 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1201 of the third network function 1200 may be configured to control the memory 1203 of the third network function 1200 to store any requests, resources, information, data, signals, or similar that are described herein.
  • Figure 13 illustrates a second network function 1300 comprising processing circuitry (or logic) 1301.
  • the processing circuitry 1301 controls the operation of the second network function 1300 and can implement the method 400 described herein in relation to a second network function 1300.
  • the processing circuitry 1301 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the second network function 1300 in the manner described herein.
  • the processing circuitry 1301 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 400 described herein in relation to the second network function.
  • the processing circuitry 1301 of the second network function 1300 is configured to: transmit, to a first network function, a first request to report information related to either detected tethering events in a session or detected tethering events for one or more services in the session; receive a first message from the first network function, the first message comprising tethering information related to either a first tethering event in the session at a first device or a first tethering event for one of the one or more services in the session at a first device.
  • the second network function 1300 may optionally comprise a communications interface 1302.
  • the communications interface 1302 of the second network function 1300 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1302 of the second network function 1300 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1301 of second network function 1300 may be configured to control the communications interface 1302 of the second network function 1300 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the second network function 1300 may comprise a memory 1303.
  • the memory 1303 of the second network function 1300 can be configured to store program code that can be executed by the processing circuitry 1301 of the second network function 1300 to perform the method 400 described herein in relation to the second network function 1300.
  • the memory 1303 of the second network function 1300 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1301 of the second network function 1300 may be configured to control the memory 1303 of the second network function 1300 to store any requests, resources, information, data, signals, or similar that are described herein.
  • Figure 14 illustrates a fourth network function 1400 comprising processing circuitry (or logic) 1401.
  • the processing circuitry 1401 controls the operation of the fourth network function 1400 and can implement the method 500 described herein in relation to a fourth network function 1400.
  • the processing circuitry 1401 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the fourth network function 1400 in the manner described herein.
  • the processing circuitry 1401 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 500 described herein in relation to the fourth network function.
  • the processing circuitry 1401 of the fourth network function 1400 is configured to: transmit, to a third network function, policy information relating at least in part to tethering events, wherein the policy information comprises one or more of: an identification of one or more services to which a first part of the policy information applies; an indication as to whether tethering is allowed for the session or allowed for the one or more services; a maximum number of devices allowed to tether for the session or allowed to tether for the one or more services; a list of device types allowed to tether for the session or allowed to tether for the one or more services.
  • the fourth network function 1400 may optionally comprise a communications interface 1402.
  • the communications interface 1402 of the fourth network function 1400 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1402 of the fourth network function 1400 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1401 of fourth network function 1400 may be configured to control the communications interface 1402 of the fourth network function 1400 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the fourth network function 1400 may comprise a memory 1403.
  • the memory 1403 of the fourth network function 1400 can be configured to store program code that can be executed by the processing circuitry 1401 of the fourth network function 1400 to perform the method 500 described herein in relation to the fourth network function 1400.
  • the memory 1403 of the fourth network function 1400 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1401 of the fourth network function 1400 may be configured to control the memory 1403 of the fourth network function 1400 to store any requests, resources, information, data, signals, or similar that are described herein.
  • FIG. 15 illustrates another third network function 1500 comprising processing circuitry (or logic) 1501.
  • the processing circuitry 1501 controls the operation of the third network function 1500 and can implement the method 600 described herein in relation to a third network function 1500.
  • the processing circuitry 1501 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the third network function 1500 in the manner described herein.
  • the processing circuitry 1501 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 600 described herein in relation to the third network function.
  • the processing circuitry 1501 of the third network function 1500 is configured to: obtain first information for use in determining policies to be applied to traffic; determine, based on the first information, a first policy to be applied to traffic of a session; transmit, to a second network function, a rule comprising at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein the rule is determined based on the first policy.
  • the third network function 1500 may optionally comprise a communications interface 1502.
  • the communications interface 1502 of the third network function 1500 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1502 of the third network function 1500 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1501 of third network function 1500 may be configured to control the communications interface 1502 of the third network function 1500 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the third network function 1500 may comprise a memory 1503.
  • the memory 1503 of the third network function 1500 can be configured to store program code that can be executed by the processing circuitry 1501 of the third network function 1500 to perform the method 600 described herein in relation to the third network function 1500.
  • the memory 1503 of the third network function 1500 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1501 of the third network function 1500 may be configured to control the memory 1503 of the third network function 1500 to store any requests, resources, information, data, signals, or similar that are described herein.
  • Figure 16 illustrates another first network function 1600 comprising processing circuitry (or logic) 1601.
  • the processing circuitry 1601 controls the operation of the first network function 1600 and can implement the method 700 described herein in relation to a first network function 1600.
  • the processing circuitry 1601 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first network function 1600 in the manner described herein.
  • the processing circuitry 1601 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 700 described herein in relation to the first network function.
  • the processing circuitry 1601 of the first network function 1600 is configured to: receive, from a second network function, a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non-tethering traffic, wherein each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • the first network function 1600 may optionally comprise a communications interface 1602.
  • the communications interface 1602 of the first network function 1600 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1602 of the first network function 1600 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1601 of first network function 1600 may be configured to control the communications interface 1602 of the first network function 1600 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the first network function 1600 may comprise a memory 1603.
  • the memory 1603 of the first network function 1600 can be configured to store program code that can be executed by the processing circuitry 1601 of the first network function 1600 to perform the method 700 described herein in relation to the first NF 1600.
  • the memory 1603 of the first network function 1600 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1601 of the first network function 1600 may be configured to control the memory 1603 of the first network function 1600 to store any requests, resources, information, data, signals, or similar that are described herein.
  • FIG. 17 illustrates another second network function 1700 comprising processing circuitry (or logic) 1701.
  • the processing circuitry 1701 controls the operation of the second network function 1700 and can implement the method 700 described herein in relation to a second network function 1700.
  • the processing circuitry 1701 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the second network function 1700 in the manner described herein.
  • the processing circuitry 1701 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 700 described herein in relation to the second network function.
  • the processing circuitry 1701 of the second network function 1700 is configured to: transmit to a first network function a request to create or update a session based on a rule, wherein the rule comprises at least one tethering policy to be applied to tethering traffic, and at least one traffic policy to be applied to other non tethering traffic, wherein each of the at least one tethering policy to be applied to the tethering traffic comprises one of more of: an identification of one or more devices to which the tethering policy is to be applied; an indication that the tethering policy is to be applied to all tethered traffic; a list of device types either allowed to tether for the session or allowed to tether for the one or more services in the session; a condition relating to a number of tethered devices, wherein the tethering policy is to be applied when the condition is fulfilled.
  • the second network function 1700 may optionally comprise a communications interface 1702.
  • the communications interface 1702 of the second network function 1700 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1702 of the second network function 1700 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1701 of second network function 1700 may be configured to control the communications interface 1702 of the second network function 1700 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the second network function 1700 may comprise a memory 1703.
  • the memory 1703 of the second network function 1700 can be configured to store program code that can be executed by the processing circuitry 1701 of the second network function 1700 to perform the method 700 described herein in relation to the first NF 1700.
  • the memory 1703 of the second network function 1700 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1701 of the second network function 1700 may be configured to control the memory 1703 of the second network function 1700 to store any requests, resources, information, data, signals, or similar that are described herein.
  • a computer program comprising instructions which, when executed by processing circuitry cause the processing circuitry to perform at least part of the method described herein.
  • a computer program product embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform at least part of the method described herein.
  • a computer program product comprising a carrier containing instructions for causing processing circuitry to perform at least part of the method described herein.
  • the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.
  • Embodiments described herein allow the network operator to control tethering, by enabling the PCF to providing different policies for a service (or PDU session), depending on the number of devices and types of devices that are tethering behind a UE.
  • Embodiments described herein also enable the PCF to provide dynamically different policies for every different device tethering behind the UE and consuming the service (or for the PDU session), by enabling the PCF to make policy decisions based on not only the number of devices and types of devices that are tethering behind a UE, but additionally dynamic conditions such as the access type or RAT-type used by the UE.
  • This enables the operator to provide a flexible configuration that enables different enforcements to be applied and/or restricts the usage of tethering depending on a number of dynamic conditions, for a large number of different tethering scenarios.
  • the provided configuration is simplified as there is no need to define different applds for the same service (separately for tethering traffic and non-tethering traffic), reducing the number of PCC rules that need to be installed by the PCF.
  • Embodiments described herein also reduce the signaling required to apply different policies for a service (or PDU session), depending on the number of devices and types of devices that are tethering behind a UE.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Selon des modes de réalisation, la présente invention concerne des procédés et des appareils pour obtenir des informations relatives à des événements de fonction modem. Un procédé mis en œuvre au niveau d'une première fonction réseau pour obtenir des informations relatives à des événements de fonction modem comprend la réception, en provenance d'une seconde fonction réseau, d'une première demande de rapport d'informations soit relatives à des événements de fonction modem détectés dans une session, soit relatives à des événements de fonction modem détectés pour un ou plusieurs services dans une session ; la détection d'un premier événement de fonction modem au niveau d'un premier dispositif ; et la transmission d'un premier message à la seconde fonction réseau, le premier message comprenant des informations de fonction modem relatives au premier événement de fonction modem.
PCT/EP2021/076130 2021-06-28 2021-09-22 Obtention d'informations relatives à des événements de fonction modem Ceased WO2023274569A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/570,285 US20250132938A1 (en) 2021-06-28 2021-09-22 Obtaining information relating to tethering events

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP21382566 2021-06-28
EP21382566.4 2021-06-28

Publications (1)

Publication Number Publication Date
WO2023274569A1 true WO2023274569A1 (fr) 2023-01-05

Family

ID=76971809

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/076130 Ceased WO2023274569A1 (fr) 2021-06-28 2021-09-22 Obtention d'informations relatives à des événements de fonction modem

Country Status (2)

Country Link
US (1) US20250132938A1 (fr)
WO (1) WO2023274569A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024035033A1 (fr) * 2022-08-09 2024-02-15 Samsung Electronics Co., Ltd. Procédé et appareil de service utilisant la fonction modem dans un système de communication sans fil

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019238252A1 (fr) * 2018-06-11 2019-12-19 Telefonaktiebolaget Lm Ericsson (Publ) Politique de fonction modem pour réseaux cellulaires
EP3641248A1 (fr) * 2017-06-13 2020-04-22 Nec Corporation Dispositif d'optimisation de trafic, système de communication, procédé d'optimisation de trafic, et programme

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10111245B2 (en) * 2014-06-26 2018-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Method and network element for scheduling

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3641248A1 (fr) * 2017-06-13 2020-04-22 Nec Corporation Dispositif d'optimisation de trafic, système de communication, procédé d'optimisation de trafic, et programme
WO2019238252A1 (fr) * 2018-06-11 2019-12-19 Telefonaktiebolaget Lm Ericsson (Publ) Politique de fonction modem pour réseaux cellulaires

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
3GPP TS 29.244
3GPP TS 29.512
3GPP TS 29.519
ZTE: "Key Issue of Tethering Control", vol. CT WG4, no. E-Meeting; 20210125 - 20210129, 27 January 2021 (2021-01-27), XP051975808, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_101e-bis_meeting/Inbox/C4-210147.zip C4-210155.zip C4-210155_was_0062_BEPoP_29820_KI of Tethering Control.docx> [retrieved on 20210127] *
ZTE: "Solution for Tethering Control", vol. CT WG4, no. E-Meeting; 20210125 - 20210129, 15 January 2021 (2021-01-15), XP051973228, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_101e-bis_meeting/Docs/C4-210063.zip C4-210063_BEPoP_29820_Solution for Tethering Control.docx> [retrieved on 20210115] *

Also Published As

Publication number Publication date
US20250132938A1 (en) 2025-04-24

Similar Documents

Publication Publication Date Title
US12015682B2 (en) Service subscription method and system for reporting service change in communication system
US12231946B2 (en) Communications method and apparatus
KR102224248B1 (ko) 통신 시스템에서 PDU(Protocol Data Unit) 세션을 설립하는 방법
EP2993926B1 (fr) Procédé et appareil de commande de politique avec pcrf et ocs
CN112042167B (zh) 用于在mec网络中处理用户服务简档信息的方法和装置
EP3837805B1 (fr) Procédés, appareil et supports lisibles par ordinateur prenant en charge des abonnements à des événements dans un réseau central
JP2023504228A (ja) アプリケーションプログラミングインタフェース（ａｐｉ）フィルタに基づくａｐｉ能力変更の報告
WO2023274366A1 (fr) Procédé et appareil d&#39;établissement de session avec une qualité de service requise
EP4312413B1 (fr) Procédés et appareils de commande de politique
EP3864888A1 (fr) Commande de notifications dans un système de communication
AU2021253086B2 (en) Alternative charging handling based on QoS
US12022326B2 (en) Policy enforcement in a 3GPP environment while ensuring congestion avoidance on user plane function northbound interfaces
US20240235940A9 (en) Controlling User Plane Function (UPF) Load
CN119404548A (zh) Af对策略评估的影响
EP3101926A1 (fr) Procédé de gestion de facturation, noeud de commande de réseau centralisé, noeud de fonction, et système
EP3900268B1 (fr) Procédés et appareil pour l&#39;analyse d&#39;une fonction de plan utilisateur
WO2023274569A1 (fr) Obtention d&#39;informations relatives à des événements de fonction modem
CN116325704A (zh) 方法、装置和计算机程序
WO2025166645A1 (fr) Procédé de résolution de conditions anormales de fonction de réseau (nf), et dispositifs associés
RU2772710C2 (ru) Способ обработки запроса и соответствующий объект
WO2025052413A1 (fr) Procédé et système pour effectuer une mise à jour de commande de politique pour une application
WO2024022601A1 (fr) Procédés et appareils de surveillance de qos
KR20240164282A (ko) Pdu 세션 정보 보고 방법 및 장치
WO2021004644A1 (fr) Procédés et appareil de fourniture d&#39;informations de contexte à un réseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21783181

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18570285

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21783181

Country of ref document: EP

Kind code of ref document: A1

WWP Wipo information: published in national office

Ref document number: 18570285

Country of ref document: US