Changes in service for ues in a communication network

Abstract

According to an aspect, there is provided a method of operating a first NF in a communication network. The method comprises receiving (1001) a first request that relates to a change in a service provided to a UE by the communication network, and if an increase in cost associated with the change in service according to the first request is permitted by an authorising party for the UE, sending (1003), to a second NF in the communication network, a second request that requests initiation of the change in service. If the increase in cost associated with the change in service according to the first request is not permitted by the authorising party for the UE, the first NF rejects (1005) the first request.

Description

[0001] Changes in service for UEs in a communication network

[0002] Technical Field

[0003] This disclosure relates to changes in service provided to a User Equipment (UE) initiated by entities external to a communication network.

[0004] There is a desire for Communication Service Providers (CSPs) to improve revenue streams by using existing functionality in their communication networks and allowing 3rdparty applications to access exposed data, as well as trigger alterations inside the CSP network. In this way, the communication network can be turned into a programmable entity (as seen from an Application Function (AF) perspective).

[0005] This disclosure relates to the activation of services in a communication network via an Application Function. Examples of the activated services include, but are not limited to:

[0006] Providing connectivity services, such as premium connectivity quality for gaming applications.

[0007] Geolocation fencing services, such as for tracking the location of children.

[0008] Parental control, including timing connectivity restrictions and website tracking.

[0009] Secure access to corporate networks.

[0010] From a cost perspective, such services can be classified according to: a) Costs derived from invoking an Application Programming Interface (API), e.g. API invocation charges (which is described further below in the sub-section “Charging of API invocations”). b) Costs accrued due to the usage of the connectivity service, e.g. the costs, typically measured in terms of time or data volume, related to the traffic delivered through the activated or modified service. This is described further below in the sub-section “Charging of the usage of the service”.

[0011] Charging of API invocations From the point of view of API invocation with respect to sponsoring and charging, two scenarios are envisioned:

[0012] 1) The Subscription Owner (e.g. an enterprise) is invoiceable for all the charges associated to the activation of the service.

[0013] 2) The API invoker is invoiceable for all the charges associated to the activation of the service. Invocations to the API generate charging records that include the invoker identity (ID) and the charging ID of the invoiceable party.

[0014] As a service management API, the following ways to charge for API usage exist:

[0015] 1. The API invoker is charged per successful invocation, either for the activation or deactivation of the service. API products are typically equipped with a quota of free invocations and a tiered or stepped price plan for invocations beyond the free limit.

[0016] 2. There can be an installation charge for the on-demand connectivity service. Potentially there can also be a recurring charge for the on-demand service for the option to activate and pause the service. In advanced charging models, the CSP may even decide to charge a different recurring charge depending on whether the service is active or paused.

[0017] 3. Usage will be charged based on the consumed resources of the service. Charging rules for service must come with an identifier of which service has been used. For example, in device connectivity services, this could be the Single-Network Slice Selection Assistance Information (SNSSAI) / Data Network Name (DNN) information, or a special rating group configured for communication on that particular network slice.

[0018] Charging for the usage of the service - Three actors / parties / entities are potentially involved in the activation / deactivation interactions: the service owner, the subscription owner, and the API invoker. For the service usage charges there are a few options:

[0019] 1. The subscription owner pays for the charges related to the usage of the service. This is a typical example in an enterprise scenario, related to connectivity services of devices, where all the charges of the enterprise network slices are invoiced to the department that owns the subscription of the device.

[0020] 2. The owner of the service pays for the traffic on that connectivity, regardless of which device uses it. An example would be an enterprise that pays for their employees to use the enterprise network slice (specifically in Bring-Your-Own-Device (BYOD) scenarios). Another example is a gaming company whose offer includes premium connectivity for their users, and therefore, pays for such connectivity to the CSP.

[0021] 3. The user of the device pays for the charges related to the usage of the service. An example could be connectivity service provided by the CSP, especially designed for gaming traffic. The user of the device can trigger the device connectivity activation and deactivation to influence the experience, and must consequently pay for the traffic, irrespective of who plays the role of the subscription owner.

[0022] This disclosure relates to the charging for the usage of the traffic, and Fig. 1 provides a simplified illustration of a User Equipment (UE) 101 and a network 102 of a CSP that provides a connectivity service. The UE 101 executes an application (APP) client 103 that communicates with an application (APP) server 104 via the network 102. The UE 101 has a UE operating system (OS) 105 and a UE modem 106, with the latter enabling communications over an air interface with a base station 107 in the network 102.

[0023] The base station 107 may be a NR (New Radio)-Standalone (SA) base station, or any other suitable type of base station. The core network of the network 102 includes a User Plane Function (UPF) 108 that handles the user data between the UE 101 / APP client 103 and the APP server 104. The core network of the network 102 also includes a Session Management Function (SMF) 109 that is connected to the UPF 108 and a Charging Function (CHF) 110. The Charging Function (CHF) 110 is responsible for charging the end user for the provision of the data service via the network 102.

[0024] The UPF 108 reports the data usage to the CHF 110, which either charges the end user ‘offline’, e.g. in a monthly invoice, or ‘online’ by deducting the data usage from the end user’s quota.

[0025] Much of the data flow consumption can be altered by a third party app, as described in 3rdGeneration Partnership Project (3GPP) Technical Standard (TS) 23.502 v18.6.0, Section 4.15.6.6 “Setting up an AF session with required QoS procedure”.

[0026] Fig. 2 is a simplified illustration of a procedure for an APP Server 104 to alter a data flow via an Application Function (AF) 116. Fig. 2 shows the UE 101 and network 102 in Fig. 1 , with some additional Network Functions (NFs) in the core network. In particular, the core network includes a Policy Control Function (PCF) 111 that provides policies for the UE 101 to the SMF 109, a Network Exposure Function (NEF) 112, a Unified Data Management (UDM) function 113, a Unified Data Repository (UDR) 114 and an Access and Mobility Management Function (AMF) 115. The Application Function (AF) 116 is external to the network 102 and communicates with the APP Server 104, and communicates with the network 102 via the NEF 112.

[0027] The procedure is as follows:

[0028] 1. The APP Server 104 detects that a change in QoS of the data flow is required and triggers the AF 116 to “upgrade” the Quality of Service (QoS), for this data flow. Note that the reason for needing or desiring the change in QoS does not impact the subsequent steps of the procedure. In some embodiments, the request for the QoS change can be triggered if the APP Server 104 determines that the current data throughput is not enough for the service being provided by the APP Server 104.

[0029] 2. The AF 116 of the Application Service Provider (ASP) contacts the network 102 of the Communication Service Provider (CSP) with the request to “upgrade” the quality of service of a data flow.

[0030] 3. The Network Exposure Function (NEF) 112 checks with an authorised source (the UDM 113) that the AF 116 (i.e. API invoker) is authorised to make the requested alteration in the network 102 of the CSP.

[0031] 4. The UDM 113 retrieves information about the AF 116 from the UDR 114, and returns this to the UDM 113. The information may indicate whether the AF 116 is allowed to make alterations in the network 102, or may indicate whether the AF 116 is allowed to make specific alterations in the network 102. The UDM 113 indicates to the NEF 112 whether the requested alterations in the network 102 by the AF 116 are allowed.

[0032] 5. If the request from the AF 116 is allowed by the authorised source (e.g. the UDM 113), then the NEF 112 contacts the Policy Control Function (PCF) 111 with the request.

[0033] 6. The PCF 111 builds the policies for this particular data flow, for this specific UE 101 , aimed at increasing one or more parameters that determine the QoS of the data flow, e.g. its bandwidth or priority. The PCF 111 sends the request to the Session Management Function (SMF) 109, with the request including updated Policy and Charging Control (PCC) rules.

[0034] 7. The SMF 109 informs the UPF 108, Radio Access Network (RAN) 107, and the UE 101 about the new QoS, and the new ‘upgraded’ QoS is delivered by the network 102 (to the extent possible).

[0035] Summary

[0036] There currently exist certain challenge(s). In particular, the sponsor of the device connection, e.g. the end user of the UE 101 or the owner of the subscription for the UE 101 , may get a very expensive bill (known as ‘bill shock’), or may use up their pre-paid account allowance meaning all services are degraded or stop working, despite the QoS increase being due to an action triggered by a party (e.g. the APP Server 104) over which the sponsor has no control.

[0037] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0038] This disclosure introduces the concept of a “payment consent principal” (which is more generally referred to herein as “authorising party”), which is a designated person or entity from which consent must be obtained prior to charging for additional services, such as providing a premium (or upgraded) QoS for some data flows. Thus, the techniques described herein enable an authorising party to interact with the network and set a desired consent level for payment agreements.

[0039] This payment consent principal is identified by data of any format, such as a Subscription Permanent Identifier (SlIPI), a Generic Public Subscription Identifier (GPSI), an Internal Group Identifier (ID), an External Group ID, or an email address. Zero or more payment consent principals can be designated for each SLIPI or GPSI. In some cases, multiple payment consent principals may be designated, each one being responsible for consenting to the provision of one or more services (here “services” are identified by data flows).

[0040] In a normal consumer scenario, the end user pays for their own bill, in which case the user of the device (UE) acts as a payment consent principal.

[0041] In a family scenario (which is also a consumer scenario), one of the family members pays a common bill covering the services for all of the family members, in which case that family member (identified by their SLIPI or GPSI) acts as the payment consent principal. There should be a link between the identifier of the payment consent principal and all the associated SLIPIs or GPSIs of the other members of the family.

[0042] In an enterprise scenario, the subscription owner (for example, the department controller) is typically the payment consent principal for all the SLIPIs or GPSIs that are under the responsibility of the subscription owner. There should be a link between the payment consent managing entity and all associated SLIPIs or GPSIs.

[0043] Embodiments can provide for consent policies to be created and controlled in the same / similar manner, and could, for example, allow the payment consent principal to allow services up to a particular cost (e.g. 10 Euros per month) to be added, and / or enable the payment consent principal to allow specific applications, e.g. identified by an App Id, and / or alter the monetary circumstances by, for example, upgrading the QoS. The same logic can also be applied to a group of Applications (defined by, e.g., Connection Capabilities). The Application grouping can also be managed / established / created during the ASP / CSP service level agreement (SLA) negotiations.

[0044] Certain embodiments may provide one or more of the following technical advantage(s). In particular, the techniques can help to avoid a “bill shock” for an end user, they can reduce or avoid consequential bad publicity for the Application Service Provider (ASP) and / or CSP, they can reduce or avoid a poor Quality of Experience (QoE) for the end user, and / or they can create or improve trust in the overall network or Application operations.

[0045] According to a first aspect, there is provided a method of operating a first NF in a communication network. The method comprises receiving a first request that relates to a change in a service provided to a UE by the communication network, and if an increase in cost associated with the change in service according to the first request is permitted by an authorising party for the UE, sending, to a second NF in the communication network, a second request that requests initiation of the change in service. If the increase in cost associated with the change in service according to the first request is not permitted by the authorising party for the UE, the first NF rejects the first request.

[0046] According to a second aspect, there is provided a method of operating a third NF in a communication network. The method comprises obtaining information indicating whether an increase in cost associated with a change in service provided to a UE is permitted or not permitted by an authorising party for the UE.

[0047] According to a third aspect, there is provided a method of operating a fourth NF in a communication network. The method comprises storing information indicating whether an increase in cost associated with a change in service provided to a UE is permitted or not permitted by an authorising party for the UE.

[0048] According to a fourth aspect, there is provided a method of operating a UE. The method comprises receiving, via Non-Access Stratum (NAS) signalling, a notification requesting an authorising party to indicate whether an increase in cost associated with a change in service provided to the UE or another UE is permitted or not permitted.

[0049] According to a fifth aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect, the second aspect, the third aspect, the fourth aspect, or any embodiments thereof.

[0050] According to a sixth aspect, there is provided a network function (NF) node, configured to perform the method according to the first aspect, the second aspect, the third aspect, the fourth aspect, or any embodiments thereof.

[0051] According to a seventh aspect, there is provided a network function (NF) node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said NF node is operative to perform the method according to the first aspect, the second aspect, the third aspect, the fourth aspect, or any embodiments thereof.

[0052] Brief Description of the Drawings

[0053] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0054] Fig. 1 provides a simplified illustration of a UE and a network of a CSP that provides a connectivity service;

[0055] Fig. 2 is a simplified illustration of a procedure for an APP Server to alter a data flow;

[0056] Fig. 3 is a simplified illustration of a procedure for an APP Server to alter a data flow according to an embodiment of the techniques described herein; Fig. 4 illustrates an exemplary procedure for the payment consent principal / authorising party to provide payment consent;

[0057] Fig. 5 illustrates another exemplary procedure for the payment consent principal / authorising party to provide payment consent;

[0058] Fig. 6 is a signalling diagram illustrating the setting up of an AF session with required QoS procedure;

[0059] Fig. 7 is a signalling diagram illustrating payment consent for an individual UE;

[0060] Fig. 8 is a signalling diagram illustrating the requesting of a UE's User Consent Subscription Data;

[0061] Fig. 9 is a signalling diagram illustrating a UE Payment Consent Setting procedure initiated by UE;

[0062] Fig. 10 is a flow chart illustrating a method performed by a first NF in accordance with some embodiments;

[0063] Fig. 11 is a flow chart illustrating a method performed by a third NF in accordance with some embodiments;

[0064] Fig. 12 is a flow chart illustrating a method performed by a fourth NF in accordance with some embodiments;

[0065] Fig. 13 is a flow chart illustrating a method performed by a UE in accordance with some embodiments;

[0066] Fig. 14 is a simplified block diagram of an apparatus in accordance with some embodiments; and

[0067] Fig. 15 is a block diagram illustrating a virtualization environment in which network functions according to some embodiments may be virtualized.

[0068] Detailed Description

[0069] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0070] As set out above, this disclosure provides solutions to enable the sponsor of a device connection, e.g. the end user of the UE 101 or the owner of the subscription for the UE 101 , to provide consent for accepting charges incurred by additional services that would increase the cost to the sponsor, before those services are provided. This can avoid the sponsor getting an unexpectedly expensive bill, or using up the pre-paid account allowance meaning all services are degraded or stop working. As noted, this disclosure introduces the concept of a “payment consent principal” (or more generally an “authorising party”), which is a designated person or entity from which consent must be obtained prior to charging for additional services, such as providing a premium (or upgraded) QoS for some data flows. Embodiments of the techniques enable an end user to interact with the network and set a desired consent level for payment agreements.

[0071] This payment consent principal is identified by data of any format, such as a Subscription Permanent Identifier (SlIPI), a Generic Public Subscription Identifier (GPSI), an Internal Group Identifier (ID), an External Group ID, or an email address. Zero or more payment consent principals can be designated for each SLIPI or GPSI. In some cases, multiple payment consent principals may be designated, each one being responsible for consenting to the provision of one or more services (here “services” are identified by data flows).

[0072] In a normal consumer scenario, the end user pays for their own bill, in which case the user of the device (UE) acts as a payment consent principal.

[0073] In a family scenario (which is also a consumer scenario), one of the family members pays a common bill covering the services for all of the family members, in which case that family member (identified by their SLIPI or GPSI) acts as the payment consent principal. There should be a link between the identifier of the payment consent principal and all the associated SLIPIs or GPSIs of the other members of the family.

[0074] In an enterprise scenario, the subscription owner (for example, the department controller) is typically the payment consent principal for all the SLIPIs or GPSIs that are under the responsibility of the subscription owner. There should be a link between the payment consent managing entity and all associated SLIPIs or GPSIs.

[0075] Embodiments can provide for consent policies to be created and controlled in the same / similar manner, and could, for example, allow the payment consent principal to allow services up to a particular cost (e.g. 10 Euros per month) to be added, and / or enable the payment consent principal to allow specific applications, e.g. identified by an App Id, and / or alter the monetary circumstances by, for example, upgrading the QoS. The same logic can also be applied to a group of Applications (defined by, e.g., Connection Capabilities). The Application grouping can also be managed / established / created during the ASP / CSP service level agreement (SLA) negotiations.

[0076] Fig. 3 is a simplified illustration of a procedure for an APP Server to alter a data flow for a particular UE 101 according to an embodiment of the techniques described herein. In this illustrated embodiment, payment consent has already been provided by the payment consent principal (the authorising party), and stored by the network 102, so the requested service change (which will result in increased cost to the UE 101 , the associated subscriber, or the authorising party) can be provided by the network 101. The network architecture shown in Fig. 3 is the same as shown in Fig. 2, so the same reference numerals are used for the same nodes. While the same nodes are shown in Fig. 3, there are differences in the operations performed by some of the nodes in the core network of the communication network 102.

[0077] It should be noted that the core network architecture shown in Fig. 3 is simplified with respect to the functionality of the AMF 115. The AMF 115 is typically in the signalling path for each SMF-to-UE or RAN interactions, but in Fig. 3 it is shown separately to better illustrate the new Non-Access Stratum (NAS) message sequence.

[0078] A procedure according to this embodiment of the techniques described herein can be as follows:

[0079] 1. The APP Server 104 detects that the current data throughput is not enough for the service and triggers the AF 116 to “upgrade” the Quality of Service (QoS), for this data flow.

[0080] 2. The AF 116 contacts the network 102 of the Communication Service Provider (CSP) with the request to “upgrade” the quality of service of a data flow.

[0081] 3. Provided that the AF 116 is authenticated with the network 102, the Network Exposure Function (NEF) 112 checks with an authorised source (the II DM 113) that the AF 116 (i.e. API invoker) is authorised to make the requested alteration in the network 102 of the CSP. In particular this check checks whether the AF 116 is authorised to make the requested alteration in the network 102 for the UE 101 or associated subscriber. Thus, in this step the NEF 112 checks that the AF 116 is authorised by the relevant authorising party for the UE 101 , as indicated by the SUPI, GPSI, or other identifier of the UE 101.

[0082] 4. The UDM 113 retrieves information about the AF 116 from the UDR 114, and returns this to the UDM 113. The information may indicate whether the AF 116 is allowed to make any types of alterations in the network 102, or may indicate whether the AF 116 is allowed to make the specific requested type of alteration in the network 102 (e.g. a maximum amount of increase in QoS). The UDM 113 indicates to the NEF 112 whether the requested alterations in the network 102 by the AF 116 are allowed.

[0083] 5. If the request from the AF 116 is allowed by the authorised source (e.g. the UDM 113), then the NEF 112 checks with the UDM 113 whether the authorising party associated with the SUPI or GPSI of the UE 101 has provided payment consent for the requested change.

[0084] 6. The UDM 113 retrieves payment consent information from the UDR 114 and returns it to the NEF 112. The payment consent information can relate to the SUPI or GPSI for the UE 101. The payment consent information can indicate whether payment consent has been provided for the requested change (or for any change). The payment consent information can also include information about the payment consent principal (the authorising party), for example an identifier or other identity information for the payment consent principal. If the UDR 114 does not have relevant payment consent information, then the UDR 114 can indicate this to the UDM 113. If the NEF 112 determines that payment consent has been given for the requested change in the service, then the NEF 112 proceeds with initiating the requested change in service. If the NEF 112 determines that payment consent has not been given for the requested change in the service, then the NEF 112 returns an error or rejection message to the AF 116.

[0085] 7. If the request from the AF 116 is allowed by the authorised source (e.g. the UDM 113), and payment consent from the authorising party has been provided, then the NEF 112 contacts the Policy Control Function (PCF) 111 with the request. If payment consent from the authorising party has not been granted, but the payment consent information indicates the identity of a payment consent principal (the authorising party), then the NEF 112 can repeat steps 5 and 6 of this procedure with the payment consent principal as the target of the request for payment consent information instead of SUPI or GPSI of the UE as the target. The repetition of steps 5 and 6 with the payment consent principal as the target of the request may indicate that authorisation of the payment has been granted, in which case the NEF 112 proceeds to contact the PCF 111 with the request; or may indicate that payment authorisation of the payment is not granted, in which case the NEF 112 returns and error rejection message to the AF 116.

[0086] 8. In response to the request from the NEF 112, the PCF 111 builds the policies for this particular data flow, for this specific UE 101 , aimed at increasing one or more parameters that determine the QoS of the data flow, e.g. its bandwidth or priority. The PCF 111 sends the request to the Session Management Function (SMF) 109, with the request including updated Policy and Charging Control (PCC) rules.

[0087] 9. The SMF 109 informs the UPF 108, Radio Access Network (RAN) 107, and the UE 101 about the new QoS, and the new ‘upgraded’ QoS is delivered by the network 102 (to the extent possible).

[0088] Thus, according to this procedure, the change in service is only provided if the authorising party has provided consent for the additional cost that would be incurred by the network delivering the change in service.

[0089] In some embodiments, the UDR 114 may contain (store) a configuration which enables a “notification to the payment consent principal” for each successful service request by the AF 116 (or by an AF associated with another APP Server 104). Specifically, for ‘family subscriptions’, e.g. where a parent is the payment consent principal, this can be used for cost control.

[0090] In some embodiments, the UDR 114 may trigger a notification (e.g. for obtaining payment consent) to the payment consent principal if a service request fails. This notification may trigger the procedures for obtaining the payment consent from the principal so that subsequent service change requests do not fail.

[0091] Fig. 4 illustrates an exemplary procedure for the payment consent principal / authorising party to provide payment consent. In this exemplary procedure, consent is obtained via a UE or other device of the authorising party. The network architecture shown in Fig. 4 is the same as shown in Fig. 3, so the same reference numerals are used for the same nodes. In a difference to Fig. 3, in Fig. 4 the UE 101 represents a UE or device of the payment consent principal, and it will be appreciated that this UE or device may be a different UE to the UE in Fig. 3 to which the service is being provided by the APP Server 104 and the network 102.

[0092] The procedure in Fig. 4 is based on bi-directional communication between the network 102 and the UE 101 via NAS.

[0093] In the case of a network-initiated payment consent authorisation request (i.e. the network 102 determines that payment consent is required and initiates the obtaining of that consent), then steps 1 , 2, 3 and the rest of the steps shown in Fig. 4 are performed. In the case of a user- initiated payment consent authorisation request (i.e. by the UE of the payment consent principal) the payment consent principal determines that payment consent is required and initiates the obtaining of that consent at step 4 in Fig. 4. Therefore, steps 1 , 2 and 3 shown in Fig. 4 are not executed, and the procedure starts with step 4.

[0094] 1. Upon receiving a trigger, e.g., due to a pending payment consent authorisation for a payment consent principal, the UDR 114 sends a notification to the UDM 113, including all the relevant payment data, such as any of: a target SUPI / GPSI for which payment consent is sought, information identifying the AF 116 that requested or requires the payment consent, the purpose of the payment that the consent will relate to, the estimated cost associated with providing the consent for the requested service change, an optional expiration date for any consent that is provided, etc.

[0095] 2. The UDM 113 sends a notification to the AMF 115 that is currently serving the UE of the payment consent principal, with the notification including the payment data.

[0096] 3. The AMF 115 sends a notification over NAS to the UE 101 of the payment consent principal, including any or all of the information contained in the notification received from the UDM 113. The UE 101 (for example at the operating system (OS) level of the UE) notifies the user of the UE 101 (i.e. the payment consent principal) and engages with the payment consent principal to request they provide acceptance or denial of the payment consent.

[0097] 4. Upon a trigger, for example receiving an acceptance or denial input to the UE 101 by the payment consent principal, the UE 101 sends a response to the AMF 115 over NAS. This response indicates whether payment consent is given (permitted / authorised) or refused (denied).

[0098] 5. The AMF 115 contacts the UDM 113 to store the result of the payment consent request and associated information (e.g. target SUPI / GPSI, AF identifier, etc.).

[0099] 6. The UDR 114 stores the result of the payment consent request (e.g. authorised / denied) along with the other information relating to the payment consent (e.g. target SUPI / GPSI, AF identifier, etc.).

[0100] Fig. 5 illustrates another exemplary procedure for the payment consent principal / authorising party to provide payment consent. In this exemplary procedure, consent is provided by the authorising party via a website or other web portal associated with the CSP. The network architecture shown in Fig. 5 is largely the same as shown in Fig. 4, so the same reference numerals are used for the same nodes, with the addition of a web server 117 in network 102. As with Fig. 4, the UE 101 represents a UE or other device (e.g. computer) of the payment consent principal, and it will be appreciated that this UE or device may be a different UE to the UE in Fig. 3 to which the service is being provided by the APP Server 104 and the network 102.

[0101] The procedure shown in Fig. 5 is based on an optional notification delivered from the AMF 115 to the UE 101 via NAS, followed by an exchange of messages between the UE 101 and a web server 117, which is shown in Fig. 5 as being part of the network 102 (although it will be appreciated that the web server 117 can be external to the network 102). It should be noted that the notification to the payment consent principal may alternatively be delivered using an alternative channel, e.g. via email (using an email address associated with the GPSI). The web server 117 may be a CSP’s self-service portal where a subscription owner can manage all of its subscriptions, and in these embodiments, grant or deny payment consent.

[0102] In the case of a network-initiated payment consent authorisation request (i.e. the network 102 determines that payment consent is required and initiates the obtaining of that consent), then steps 1 , 2, 3 and the rest of the steps shown in Fig. 5 are performed. In the case of a user- initiated payment consent authorisation request (i.e. by the UE of the payment consent principal), the payment consent principal determines that payment consent is required and initiates the obtaining of that consent at step 4 in Fig. 5. Therefore, steps 1 , 2 and 3 shown in Fig. 5 are not executed, and the procedure starts with step 4. 1. Upon receiving a trigger, e.g., due to a pending payment consent authorisation for a payment consent principal, the UDR 114 sends a notification to the UDM 113, including all the relevant payment data, such as any of: a target SUPI / GPSI for which payment consent is sought, information identifying the AF 116 that requested or requires the payment consent (including information identifying the AF 116 in a human-readable format), the purpose of the payment that the consent will relate to, the estimated cost associated with providing the consent for the requested service change, an optional expiration date for any consent that is provided, etc.

[0103] 2. The UDM 113 sends a notification to the AMF 115 that is currently serving the UE of the payment consent principal, with the notification including the payment data.

[0104] 3. The AMF 115 sends a notification over NAS to the UE 101 of the payment consent principal, including any or all of the information contained in the notification received from the UDM 113. The notification to the UE 101 can also include a link to a web page where the data can be consulted, modified, and the payment consent granted or denied. The UE 101 (for example at the operating system (OS) level of the UE) notifies the user of the UE 101 (i.e. the payment consent principal) that payment consent is required and presents the link to the web page.

[0105] 4. By selecting the link, the UE 101 (e.g. a web browser installed on the UE 101) contacts the web server 117, which duly authenticates the user, for example by the user entering a username and / or password, performing two-factor authentication, etc. This authentication of the user is not shown in Fig. 5.

[0106] 5. The web server 117 retrieves the relevant payment consent information from the UDR 114 (e.g. the SUPI / GPSI, AF identifier, etc.).

[0107] 6. The web server 117 returns the current payment consent information to the UE 101 , along with any data (e.g. Cascading Style Sheet (CSS) data) required for proper formatting and display of the web page through which consent is to be provided.

[0108] 7. The web page is displayed to the user on the UE 101 and when the user inputs or modifies the payment consent information, e.g. by authorising or revoking consent to a particular payment or increased cost, steps similar to steps 4 to 6 are performed to store information about the new / updated payment consent in the UDR 114. The UDR 114 stores the result of the payment consent request (e.g. authorised / denied) along with the other information relating to the payment consent (e.g. target SUPI, AF identifier, etc.).

[0109] The following description and Figs. 6-9 provides an exemplary implementation of the techniques described herein into the 3GPP standards.

[0110] The following modifications (indicated in bold and underline) can be made to Annexes V.2 and V.3 in 3GPP TS 33.501 v18.6.0 to also include payment consent: *************************************************************************************************************

[0111] V.2 Requirements

[0112] The UDM shall support the following services related to the user consent.

[0113] Retrieval of user consent parameters.

[0114] Notification of user consent parameters change.

[0115] The user consent parameters shall be stored in the UDM / UDR as subscription data.

[0116] The user consent parameters shall be bound to a SUPI / GPSI.

[0117] The user consent parameters shall include information on a payment consent principal (e.g. a delegate), who shall handle user consent requests.

[0118] The user consent parameters shall be bound to the purpose of data processing, or

[0119] The user consent parameters shall additionally be bound to the purpose of payments, e.g. when generating additional cost, including information about the service reguestor (AF Id).

[0120] The user consent parameters shall include whether the user consent is granted or not.

[0121] The user consent shall be effective only after the point in time that user consent was given. The user consent shall be effective until revoked. It means that there is no expiry / validity timer for the user consent parameters stored in the subscription data.

[0122] NOTE: UDM does not provide user consent revocation service, it only provides notifications of user consent parameter changes.

[0123] V.3 User consent check

[0124] Any NF that is deemed an enforcement point for user consent shall support to retrieve the user consent parameters from the UDM.

[0125] Any NF that is deemed an enforcement point for user consent shall not accept any services or requests for data processing unless user consent is granted.

[0126] Any NF that is deemed an enforcement point for user consent shall determine the purpose of data processing prior to the data processing. If the purpose of data processing is not implicitly known from the service request, the user consent enforcement point shall request it or otherwise deny the service.

[0127] If the purpose of data processing is connected to payment processes the request shall be denied if the consent charging principal hasn’t explicitly granted it. NFs obtaining or checking the user consent parameters shall consider the user consent parameters as effective until revoked. *************************************************************************************************************

[0128] The following modifications (indicated in bold and underline) can be made to Section 4.15.6.6 “Setting up an AF session with required QoS procedure” in 3GPP TS 23.502 v18.6.0 to also include payment consent: ************************************************************************************************************* 4.15.6.6 Setting up an AF session with required QoS procedure

[0129] Fig. 6 shows Figure 4.15.6.6-1 : Setting up an AF session with required QoS procedure

[0130] 2. The NEF authorizes the AF request that contains a single UE address and may apply policies to control the overall amount of QoS authorized for the AF. If the authorisation is not granted, all steps (except step 5) are skipped and the NEF replies to the AF with a Result value indicating that the authorisation failed. The NEF assigns a Transaction Reference ID to the Nnef_AFsessionWithQoS_Create request.

[0131] 2a. The NEF shall convert / map the UE IP Address to the GPSI using the procedure described in clause 4.15.10 AF specific UE ID retrieval

[0132] 2b. The NEF may need to authorize the service specific parameter provisioning reguest with the UDM by sending a Nudm SDM Get service operation as defined in clause 4.15.6.x.

[0133] NOTE 2: The determination can also be based on an SLA between operator and application provider, e.g. using the DNN / S-NSSAI for the AF session according to the SLA. *************************************************************************************************************

[0134] The following new section and the signalling diagram in Fig. 7 can be added as Section 4.15.6.x in 3GPP TS 23.502 v18.6.0: ************************************************************************************************************* 4.15.6.x Authorization of payment consent Fig. 7 (to be labelled in the standards as Figure 4.15.6.x) shows the procedure to authorize the payment consent making allowing an external Application / AF to alter the QoS which may increase the cost for the end user (e.g. for Setting up an AF session with required QoS as defined in clause 4.15.6.6).

[0135] Fig. 7 shows Figure 4.15.6.x: Payment Consent for an individual UE

[0136] The NEF initiates the procedure as specified in clause 4.15.6.6.

[0137] 1. The NEF contacts UDM to request the payment consent information for a SlIPI or GPSI using Nudm_SDM_Get including data type "User consent" and the API invoker Id (AF ID).

[0138] The data type shall be equal to “Payment Consent” as described in 3GPP TS 29.503 v18.6.0. The NEF may need to convert the GPSI to SUPI prior to this step.

[0139] Note: In order to make the consent query optional it is suggested to trigger it configurable per AF / Group of AFs, this grouping can also be decided in the ASP / CSP SLA.

[0140] 1b. The UDM maps the GPSI included in the request from the NEF to SUPI or Internal Group Id.

[0141] 2. The UDM queries UDR for retrieving the Payment consent information for the SUPI from the subscription data for the AF ID.

[0142] 3. UDR returns the Payment consent information of the SUPI.

[0143] 4. The UDM responds to the NEF with the payment consent information of the target GPSI and for the AF Id. This information includes: a) Whether payment consent is already granted or not for this AF ID b) Optionally, an identifier of the payment consent principal who must provide the payment consent in case it is not granted. The identifier may be a SUPI, GPSI, internal Group ID, external Group ID, e-mail address, or similar. c) Optionally, an expiration date.

[0144] 5. If the payment consent information indicates that payment consent is not granted and the payment consent principal identifier is included, different from the target SUPI, the NEF contacts UDM once more, in a similar operation as in step 1 , requesting the payment consent information, but now for the identifier of the payment consent principal.

[0145] 6. UDM queries UDR for the Payment consent information of the SUPI of the payment consent principal and the AF ID.

[0146] 7. UDR delivers the requested Payment consent information. 8. UDM returns the payment consent information of the payment consent principal. NEF applies the received information to the target SlIPI and AF ID.

[0147] If payment consent is consent not granted, the NEF rejects the request with the proper error code to inform the AF about the request not being authorized.

[0148] The procedure continues as specified in clause 4.15.6.6.

[0149] Note: The Common API Framework for 3GPP northbound APIs (CAPIF) framework specified in 3GPP TS 23.222 v19.2.0 and 3GPP TS 29.222 v18.6.0 include a service operation for discovery of services (CAPIF_Discovery_Service API). This allows an AF to query the NEF for available APIs. The NEF returns the list of available APIs, and for each of them, among other data, the list of api-supported-features and supported-features attributes. APIs affected requirement payment consent would need to indicate a “payment consent required” feature.

[0150] *************************************************************************************************************

[0151] The following modifications (indicated in bold and underline) can be made to the following sections of 3GPP TS 29.503 v18.6.0 to also include payment consent:

[0152] *************************************************************************************************************

[0153] 5.2.2.2.24 User Consent Subscription Data Retrieval

[0154] Fig. 8 (to be labelled in the standards as Figure 5.2.2.2.24-1 shows a scenario where the NF service consumer (e.g. Network Data Analytics Function (NWDAF), Data Collection Coordination Function (DCCF), NEF, trusted AF) sends a request to the UDM to receive the UE's User Consent Subscription Data. The request contains the UE's identity ( / {supi}), the type of the requested information ( / uc-data) and query parameters (uc-purpose and / or supported-features).

[0155] Fig. 8 shows Figure 5.2.2.2.24-1 : Requesting a UE's User Consent Subscription Data

[0156] 1. The NF service consumer (e.g. NWDAF, DCCF, NEF, trusted AF) sends a GET request to the resource representing the UE's User Consent Subscription Data, with query parameters indicating the uc-purpose and / or supported-features.

[0157] 2a. On Success, the UDM responds with "200 OK" with the message body containing the UE's User Consent Subscription Data as relevant for the requesting NF service consumer.

[0158] On failure, the appropriate Hypertext Transfer Protocol (HTTP) status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

[0159] *************************************************************************************************************

[0160] 6.1.3.32 Resource: UcSubscriptionData (Document)

[0161] 6.1.3.32.1 Description

[0162] This resource represents the subscribed User Consent Data for a UE as defined in Annex V.2 of 3GPP TS 33.501 [6], clause 5.1.3 of 3GPP TS 33.558

[0063] and clause 6.2 of 3GPP TS 23.288

[0035] , It is queried by the NWDAF, DCCF, NEF and trusted AF (e.g. EES).

[0163] 6.1.3.32.2 Resource Definition

[0164] Resource Uniform Resource Indicator (URI): {apiRoot} / nudm-sdm / <apiVersion> / {supi} / uc-data This resource shall support the resource URI variables defined in table 6.1.3.32.2-1.

[0165] Table 6.1.3.32.2-1 : Resource URI variables for this resource

[0166] 6.1.3.32.3 Resource Standard Methods

[0167] 6.1.3.32.3.1 GET

[0168] This method shall support the URI query parameters specified in table 6.1.3.32.3.1-1.

[0169] Table 6.1.3.32.3.1-1 : URI query parameters supported by the GET method on this resource

[0170] UDM shall return the User Consent Subscription Data for the UE identified by the supi.

[0171] This method shall support the request data structures specified in table 6.1.3.32.3.1-2 and the response data structures and response codes specified in table 6.1.3.32.3.1-3.

[0172] 6.1.6.3.20 Enumeration: UcPurpose

[0173] Table 6.1.6.3.20-1: Enumeration UcPurpose

[0174] The following modifications (indicated in bold and underline) can be made to the following sections of 3GPP TS 23.502 to also include payment consent:

[0175] *************************************************************************************************************

[0176] 6.1x UE Payment Consent Setting Procedure

[0177] 6.1x.1 UE Payment Consent Setting Procedure Initiated by UE

[0178] Fig. 9 shows Figure 6.1x.1-1: UE Payment Consent Setting procedure initiated by UE

[0179] 1. If the UE has generated or updated the UE Payment Consent Setting, the UE sends the UE Payment Consent Setting to the AMF via UE Payment Consent Setting Request in N1 NAS message. The UE Payment Consent Setting indicates whether it allows or disallows the subseguent QoS related AF reguests (AF Id specific) for the UE, as defined in clause 4.15.6.6.

[0180] 2. The AMF invokes a Nudm SDM Update (User Consent) service operation towards the UDM and the service operation carries the UE Payment Consent Setting information.

[0181] 3. The UDM stores or updates the UE Payment Consent Setting in the UDR by invoking a Nudr DM Update (SUPI, Subscription Data) service operation accordingly.

[0182] 4. The UDM responds back to the AMF

[0183] 5. The AMF responses to the UE via UE Payment Consent Setting Response in N1 NAS message.

[0184] 6. UDM notifies the subscribed Network Function (Le. NEF) of the updated UE Payment Consent Setting via Nudm SDM Notification Notify message.

[0185] NOTE: The content of the UE Payment Consent Setting IE could include specific Applications or group of Applications that the end-user consents to.

[0186] *************************************************************************************************************

[0187] Fig. 10 is a flow chart illustrating a method according to various embodiments performed by a first network function (NF) in a communication network. The first NF may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0188] The first NF can be a node that exposes functions of the communication network to other NFs, nodes or entities, and in particular embodiments the first NF is a NEF.

[0189] In step 1001 , the first NF receives a first request that relates to a change in a service provided to a UE by the communication network. The first request may be received from an AF or an Application Server.

[0190] In step 1003, if an increase in cost associated with the change in service according to the first request is permitted by an authorising party for the UE, the first NF sends a second request to a second NF in the communication network that requests initiation of the change in service. The second NF can be a node that sets and / or modifies policies for UEs in the communication network, and in particular embodiments the second NF can be a PCF.

[0191] Alternatively, if the increase in cost associated with the change in service according to the first request is not permitted by the authorising party for the UE, then in step 1005 the first NF rejects the first request.

[0192] The authorising party may be a user of the UE, or an owner of a subscription for the UE.

[0193] In some embodiments, the first NF can send a third request to a third NF (for example a UDM function), with the third request requesting information relating to whether the increase in cost associated with the change in service according to the first request is permitted. The third request can comprise any of: an identifier for an entity, NF or node that the first request was received from, an identifier for the service provided to the UE, an identifier for the provider of the service to the UE, information relating to the change in service in the first request, an identifier for the UE, an identifier for a subscriber associated with the UE, a SUPI or a GPSI.

[0194] After the third request is sent to the third NF, or, in some embodiments, regardless of whether a third request is sent to the third NF, the method can further comprise receiving, from the third NF, information indicating whether the increase in cost associated with the change in service according to the first request is permitted or not permitted. This information can be received prior to steps 1003 and 1005, in which case step 1003 or 1005 is performed based on the information received from the third NF. In some embodiments, this information is received prior to step 1001.

[0195] Fig. 11 is a flow chart illustrating a method according to various embodiments performed by a third network function (NF) in a communication network. The third NF may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0196] The third NF may be a UDM function.

[0197] In step 1101 , the third NF obtains information indicating whether an increase in cost associated with a change in service provided to a UE is permitted or not permitted by an authorising party for the UE.

[0198] In some embodiments, step 1101 comprises receiving the information from a fourth NF in the communication network. The information may be received from the fourth NF in response to the third NF sending a fourth request to the fourth NF that requests information on whether the increase in cost associated with the change in service is permitted or not permitted. The fourth NF may be an UDR.

[0199] In some embodiments, the third NF can receive information identifying the authorising party, and / or identifying a UE or device associated with the authorising party. This information can be received from the fourth NF. The information can be received with the other information in step 1101 , or received separately.

[0200] In some embodiments, the third NF may trigger a notification to the identified UE or other device associated with the authorising party. This notification requests the authorising party to indicate whether the increase in cost associated with the change in service is permitted or not permitted. This notification can be triggered via a fifth NF in the communication network. The fifth NF may be a NF that manages access and mobility of UEs in the communication network, such as. an AMF. The information received in step 1101 may be received in response to this notification.

[0201] The notification can comprise a link to a web server associated with the communication network through which the authorising party can indicate whether the increase in cost associated with the change in service is permitted or not permitted.

[0202] The method may further comprise the step of receiving, from a first NF in the communication network, a third request that requests information relating to whether the increase in cost associated with the change in service is permitted. In these embodiments, the information can be obtained in step 1101 in response to receiving the third request. The first NF may be a node that exposes functions of the communication network to other NFs, nodes or entities, for example a NEF.

[0203] The third request may comprise any of: an identifier for an entity, NF or node that the service relates to, an identifier for the service provided to the UE, information relating to the change in service, an identifier for the UE, an identifier for the provider of the service to the UE, an identifier for a subscriber associated with the UE, a SUPI, or a GPSI.

[0204] The method may further comprise sending the information indicating whether the increase in cost associated with the change in service is permitted or not permitted by the authorising party to the first NF.

[0205] Fig. 12 is a flow chart illustrating a method according to various embodiments performed by a fourth network function (NF) in a communication network. The fourth NF may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0206] The fourth NF may be a data storage node, such as a UDR.

[0207] In step 1201 , the fourth NF stores information indicating whether an increase in cost associated with a change in service provided to a UE is permitted or not permitted by an authorising party for the UE.

[0208] The stored information indicating whether an increase in cost associated with a change in service provided to a UE is permitted or not permitted by an authorising party for the UE may have been received from a web server or a third NF in the communication network.

[0209] The method at the fourth NF can further comprise receiving a fourth request from a third NF that requests information relating to whether the increase in cost associated with the change in service is permitted. The fourth request can comprise any of: an identifier for an entity, NF or node that is external to the communication network that the service relates to, an identifier for the service provided to the UE, information relating to the change in service, an identifier for the UE, an identifier for a subscriber associated with the UE, a SUPI or a GPSI.

[0210] In some embodiments, the fourth NF sends, to the third NF, the stored information indicating whether the increase in cost associated with the change in service is permitted or not permitted by the authorising party for the UE.

[0211] The fourth NF may store information identifying an authorising party for the UE, and / or identifying a UE or device associated with the authorising party. In these embodiments, the fourth NF can send, to the third NF, the stored information identifying the authorising party for the UE, and / or identifying a UE or device associated with the authorising party.

[0212] In the above embodiments, the third NF can be a UDM function.

[0213] Fig. 13 is a flow chart illustrating a method according to various embodiments performed by a UE in a communication network. The UE may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0214] In step 1301 , the UE receives a notification requesting an authorising party to indicate whether an increase in cost associated with a change in service provided to the UE or another UE is permitted or not permitted. This notification is received via NAS signalling.

[0215] In some embodiments, the notification comprises a link to a web server through which the authorising party can provide the indication of whether the increase in cost associated with a change in service is permitted or not permitted.

[0216] In alternative embodiments, after step 1301 , the UE receives an input from the user of the UE that indicates whether the increase in cost associated with the change in service provided to the UE or another UE is permitted or not permitted. The UE then sends a response to the communication network via NAS signalling. The response is based on the received input and indicates whether the increase in cost associated with the change in service provided to the UE or another UE is permitted or not permitted.

[0217] The notification received in step 1301 can comprise any of: an identifier for an entity, network function or node that is requesting the change in service, an identifier for the service provided to the UE or the another UE, and information relating to the change in service.

[0218] Fig. 14 is a simplified block diagram of an apparatus 1400 that can be used to implement, or implement part of, the techniques described herein. In particular, the apparatus 1400 may be, or be a part of, a computer, a server, a network function, or a node in a communication network. In particular embodiments, the apparatus 1400 can be configured or adapted to perform the method performed by any one or more of the NFs shown in Figs. 3-9, of the method shown in any one or more of Figs. 10-13.

[0219] The apparatus 1400 comprises processing circuitry (or logic) 1401. It will be appreciated that the apparatus 1400 may comprise one or more virtual machines running different software and / or processes. The apparatus 1400 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0220] The processing circuitry 1401 controls the operation of the apparatus 1400 to implement any of the methods described herein. 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 apparatus 1400 in the manner described herein. In particular implementations, 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 described herein in relation to the apparatus 1400.

[0221] The apparatus 1400 also comprises a communications interface 1402. The communications interface 1402 is for use in enabling communications with other apparatus, nodes, computers, servers, etc. For example, the communications interface 1402 can be configured to transmit to and / or receive from other nodes, requests, acknowledgements, information, data, signals, or similar. The communications interface 1402 can use any suitable communication technology.

[0222] The processing circuitry 1401 may be configured to control the communications interface 1402 to transmit to and / or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein. The apparatus 1400 may comprise a memory 1403. In some embodiments, the memory 1403 can be configured to store program code that can be executed by the processing circuitry 1401 to perform the methods described herein in relation to the apparatus 1400. Alternatively or in addition, the memory 1403 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 1401 may be configured to control the memory 1403 to store such information therein.

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

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

[0225] Hardware 1504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1508a and 1508b (one or more of which may be generally referred to as VMs 1508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1506 may present a virtual operating platform that appears like networking hardware to the VMs 1508. The VMs 1508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1506. Different embodiments of the instance of a virtual appliance 1502 may be implemented on one or more of VMs 1508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

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

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

[0228] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0229] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0230] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

Claims1. A method of operating a first network function, NF, in a communication network, the method comprising: receiving (1001) a first request that relates to a change in a service provided to a User Equipment, UE, by the communication network; if an increase in cost associated with the change in service according to the first request is permitted by an authorising party for the UE, sending (1003), to a second NF in the communication network, a second request that requests initiation of the change in service; and if the increase in cost associated with the change in service according to the first request is not permitted by the authorising party for the UE, rejecting (1005) the first request.

2. The method as claimed in claim 1 , wherein the first NF is a node that exposes functions of the communication network to other NFs, nodes or entities.

3. The method as claimed in claim 1 or 2, wherein the first NF is a Network Exposure Function, NEF.

4. The method as claimed in any of claims 1-3, wherein the second NF is a node that sets and / or modifies policies for UEs in the communication network.

5. The method as claimed in any of claims 1-4, wherein the second NF is a Policy Control Function, PCF.

6. The method as claimed in any of claims 1-5, wherein the method further comprises the step of: receiving, from a third NF in the communication network, information indicating whether the increase in cost associated with the change in service according to the first request is permitted or not permitted.

7. The method as claimed in claim 6, wherein the steps of sending (1003) and rejecting (1005) are performed based on the information received from the third NF.

8. The method as claimed in claim 6 or 7, wherein the method further comprises:sending, to the third NF, a third request that requests information relating to whether the increase in cost associated with the change in service according to the first request is permitted.

9. The method as claimed in claim 8, wherein the third request comprises any of: an identifier for an entity, NF or node that the first request was received from, an identifier for the service provided to the UE, an identifier for the provider of the service to the UE, information relating to the change in service in the first request, an identifier for the UE, an identifier for a subscriber associated with the UE, a Subscription Permanent Identifier, SUPI, or a Generic Public Subscription Identifier, GPSI.

10. The method as claimed in any of claims 6-9, wherein the third NF is a Unified Data Management, UDM, function.

11. The method as claimed in any of claims 1-10, wherein the first request is received from an Application Function, AF, or an Application Server.

12. The method as claimed in any of claims 1-11, wherein the authorising party is a user of the UE, or an owner of a subscription for the UE.

13. A method of operating a third network function, NF, in a communication network, the method comprising: obtaining (1101) information indicating whether an increase in cost associated with a change in service provided to a User Equipment, UE, is permitted or not permitted by an authorising party for the UE.

14. The method as claimed in claim 13, wherein the method further comprises: receiving, from a first NF in the communication network, a third request that requests information relating to whether the increase in cost associated with the change in service is permitted, wherein the information is obtained in response to receiving the third request.

15. The method as claimed in claim 14, wherein the third request comprises any of: an identifier for an entity, NF or node that the service relates to, an identifier for the service provided to the UE, an identifier for the provider of the service to the UE, information relating to the change in service, an identifier for the UE, an identifier for a subscriber associated with the UE, a Subscription Permanent Identifier, SUPI, or a Generic Public Subscription Identifier, GPSI.

16. The method as claimed in any of claims 13-15, wherein the method further comprises: sending, to a first NF in the communication network, the information indicating whether the increase in cost associated with the change in service is permitted or not permitted by the authorising party for the UE.

17. The method as claimed in any of claims 13-16, wherein the first NF is a node that exposes functions of the communication network to other NFs, nodes or entities.

18. The method as claimed in any of claims 13-17, wherein the first NF is a Network Exposure Function, NEF.

19. The method as claimed in any of claims 13-18, wherein the step of obtaining comprises receiving, from a fourth NF in the communication network, information indicating whether the increase in cost associated with the change in service is permitted or not permitted.

20. The method as claimed in any of claims 13-19, wherein the method further comprises: sending, to a fourth NF in the communication network, a fourth request that requests information on whether the increase in cost associated with the change in service is permitted or not permitted.

21. The method as claimed in any of claims 13-20, wherein the method further comprises: receiving, from a fourth NF in the communication network, information identifying the authorising party, and / or identifying a UE or device associated with the authorising party.

22. The method as claimed in claim 21 , wherein the method further comprises the step of: triggering, via a fifth NF in the communication network, a notification to the identified UE or other device associated with the authorising party, wherein the notification requests the authorising party to indicate whether the increase in cost associated with the change in service is permitted or not permitted.

23. The method as claimed in claim 22, wherein the notification comprises a link to a web server associated with the communication network through which the authorising party can indicate whether the increase in cost associated with the change in service is permitted or not permitted.

24. The method as claimed in claim 22 or 23, wherein the fifth NF manages access and mobility of UEs in the communication network.

25. The method as claimed in any of claims 22-24, wherein the fifth NF is an Access and Mobility Management Function, AMF.

26. The method as claimed in any of claims 20-25, wherein the fourth NF is a Unified Data Repository, UDR.

27. The method as claimed in any of claims 13-26, wherein the third NF is a Unified Data Management, UDM, function.

28. A method of operating a fourth network function, NF, in a communication network, the method comprising: storing (1201) information indicating whether an increase in cost associated with a change in service provided to a User Equipment, UE, is permitted or not permitted by an authorising party for the UE.

29. The method as claimed in claim 28, wherein the method further comprises: receiving, from a third NF in the communication network, a fourth request that requests information relating to whether the increase in cost associated with the change in service is permitted.

30. The method as claimed in claim 29, wherein the fourth request comprises any of: an identifier for an entity, NF or node that the service relates to, an identifier for the service provided to the UE, an identifier for the provider of the service to the UE, information relating to the change in service, an identifier for the UE, an identifier for a subscriber associated with the UE, a Subscription Permanent Identifier, SUPI, or a Generic Public Subscription Identifier, GPSI.

31. The method as claimed in any of claims 28-30, wherein the method further comprises: sending, to a third NF in the communication network, the stored information indicating whether the increase in cost associated with the change in service is permitted or not permitted by the authorising party for the UE.

32. The method as claimed in any of claims 28-31 , wherein the method further comprises:storing information identifying an authorising party for the UE, and / or identifying a UE or device associated with the authorising party.

33. The method as claimed in claim 32, wherein the method further comprises: sending, to a third NF in the communication network, the stored information identifying the authorising party for the UE, and / or identifying a UE or device associated with the authorising party.

34. The method as claimed in any of claims 28-33, wherein the stored information indicating whether an increase in cost associated with a change in service provided to a UE is permitted or not permitted by an authorising party for the UE was received from a web server or a third NF in the communication network.

35. The method as claimed in any of claims 28-34, wherein the third NF is a Unified Data Management, UDM, function.

36. The method as claimed in any of claims 28-35, wherein the fourth NF is a data storage node.

37. The method as claimed in any of claims 28-36, wherein the fourth NF is a Unified Data Repository, UDR.

38. A method of operating a User Equipment, UE, the method comprising: receiving (1301), via Non-Access Stratum, NAS, signalling, a notification requesting an authorising party to indicate whether an increase in cost associated with a change in service provided to the UE or another UE is permitted or not permitted.

39. The method as claimed in claim 38, wherein the notification comprises a link to a web server through which the authorising party can provide the indication of whether the increase in cost associated with a change in service is permitted or not permitted.

40. The method as claimed in claim 38, wherein the method further comprises: receiving, from a user of the UE, an input indicating whether the increase in cost associated with the change in service provided to the UE or another UE is permitted or not permitted; andsending, to the communication network, via NAS signalling, a response that is based on the received input and indicates whether the increase in cost associated with the change in service provided to the UE or another UE is permitted or not permitted.

41. The method as claimed in any of claims 38-40, wherein the received notification comprises any of: an identifier for an entity, network function or node that is requesting the change in service, an identifier for the service provided to the UE or the another UE, and information relating to the change in service.

42. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-41 .

43. A network function, NF, node, configured to perform the method of any of claims 1-41.

44. A network function, NF, node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said NF node is operative to perform the method of any of claims 1-41.

Images