WO2025200027A1

WO2025200027A1 - Access control on internet protocol multimedia subsystem data channel service exposure

Info

Publication number: WO2025200027A1
Application number: PCT/CN2024/085068
Authority: WO
Inventors: Jing PING; Shi Wen Liu; Saurabh Khare
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Priority date: 2024-03-29
Filing date: 2024-03-29
Publication date: 2025-10-02
Anticipated expiration: 2026-09-29

Abstract

Example embodiments of the present disclosure are directed to access control on internet protocol multimedia subsystem (IMS) data channel (DC) service exposure. A method comprises: receiving a request of a service associated with a DC communication in an IMS; determining whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and causing, based on the determination, the service associated with the DC communication to be exposed to a DC application server.

Description

ACCESS CONTROL ON INTERNET PROTOCOL MULTIMEDIA SUBSYSTEM DATA CHANNEL SERVICE EXPOSURE

FIELDS

Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for access control on internet protocol multimedia subsystem (IMS) data channel (DC) service exposure.

BACKGROUND

The study aims at investigating the security impacts of the new features of the Next Generation Real Time Communication (RTC) has been discussed. More specifically the study aims at IMS third party identity security handling, the security handling of the enhancements to IMS media plane to support the use cases of IMS based Metaverse services and IMS data channel service exposure security.

SUMMARY

In a first aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive a request of a service associated with a DC communication in an IMS; determine whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and cause, based on the determination, the service associated with the DC communication to be exposed to a DC application server.

In a second aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from one of a Network Exposure Function (NEF) or an IMS application server (AS) or a DCSF, information associated with a request of a service associated with a DC communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and transmit, to one of the NEF or the IMS AS or the data channel signaling function (DCSF) , an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.

In a third aspect of the present disclosure, there is provided a method. The method comprises: receiving a request of a service associated with a DC communication in an IMS; determining whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and causing, based on the determination, the service associated with the DC communication to be exposed to a DC application server.

In a fourth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a DC communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and transmitting, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.

In a fifth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving a request of a service associated with a DC communication in an IMS; means for determining whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and means for causing, based on the determination, the service associated with the DC communication to be exposed to a DC application server.

In a sixth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a DC communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and means for transmitting, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.

In a seventh aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the third aspect.

In an eighth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the fourth aspect.

It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described with reference to the accompanying drawings, where:

FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

FIG. 2 illustrates a signaling chart of communication according to some example embodiments of the present disclosure;

FIG. 3 illustrates a signaling chart of communication according to some example embodiments of the present disclosure;

FIG. 4 illustrates a signaling chart of communication according to some example embodiments of the present disclosure;

FIG. 5 illustrates a flowchart of a method implemented at an apparatus in accordance with some example embodiments of the present disclosure;

FIG. 6 illustrates a flowchart of a method implemented at an apparatus in accordance with some example embodiments of the present disclosure;

FIG. 7 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

FIG. 8 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first, ” “second, ” …, etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable) :

(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and

(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , 5.5G, the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

Furthermore, the term “communication network” may also refer to IMS, which may comprises all core network elements for provision of multimedia services. This includes the collection of signalling and media related network elements. IP multimedia services are based on an IETF defined session control capability which, along with multimedia transport capabilities, utilises the IPConnectivity Access Network. The IMS may enable operators to offer their subscribers multimedia services. The IM CN subsystem should enable the convergence of, and access to, voice, video, messaging, data and web-based technologies for the wireless and wireline user.

As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and/or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented. The communication environment 100 may comprises a NEF 110, which may be located between the 5G core network and external third-party application functionaries (and possibly some internal AFs) and responsible for managing the external open network data, and all external applications that want to access the internal data of the 5G core must pass through the NEF 110.

For example, the NEF 110 in the communication environment 100 may be communicate with a DC application server 140 (DC AS) and may decide whether one or more DC associated service is to be exposed to the DC AS 140.

The communication environment 100 may also comprises a unified data management (UDM) /home subscriber server (HSS) 120 and an IMS application server (IMS AS) /data channel signaling function (DCSF) 130, which may communicate with the NEF 110 and help the NEF 110 to authorize the request of DC associated service and/or provide the DC associated service.

It is to be understood that the communication environment 100 may comprise one or more other network entities/functions, such as policy control function (PCF) and/or policy and charging rules function (PCRF) , which are not shown in FIG. 1.

Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , 5.5G, the sixth generation (6G) , and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

There are two Key Issues (KIs) related to data channel (DC) service exposure, namely Key Issue #1: extensible IMS mechanism supporting IMS events in the context of DC communication and Key issue #2: impact on IMS architecture, interfaces and procedures to support IMS capability exposure in the context of IMS data channel session.

However, some aspects of these issues had not discussed yet. For example, policies and procedure to support authorization of application function (AF) for DC event and session control exposure and privacy protection in DC event exposure procedure are still missing. Furthermore, how to bind DC application with DC in DC session control exposure scenario still needs to be clarified. Also, new/extended interfaces between NEF, DCSF, IMS AS, HSS/UDM, PCF/PCRF, to support exchanging authorization/privacy policies and decisions needs to be developed.

In this situation, the DC service exposure solutions requires NEF to securely expose DC services to AF. From security point of view, without proper access control, the IMS DC services may be illegally used by malicious application function/server (AF/AS) , and cause compromising on confidentiality, integrity, availably and privacy of IMS system and end users.

Therefore, authentication and authorization of AF/AS, especially external AF/AS, are mandatory to enable operator to securely share IMS DC services to an AF without leaking sensitive user information to unauthorized third party or losing availability of service caused by unauthorized control from the unauthorized third party. In addition, privacy protection is important to deploy DC service without violate regulation.

In accordance with some example embodiments of the present disclosure, there is provided a solution for IMS DC service exposure. In this solution, NEF 110 receives, from a DC AS 140, a request of a service associated with a DC communication in an IMS. The NEF 110 may determine whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function. Based on the determination, the NEF 110 cause the service associated with the DC communication to be exposed to a DC application server.

Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

The reference now is made to FIG. 2, which illustrates a signaling flow 200 of communication in accordance with some embodiments of the present disclosure. For the purposes of discussion, the signaling flow 200 will be discussed with reference to FIG. 1, for example, by using the NEF 110, the HSS/UDM 120, the IMS AS/DSCF 130 and DC AS 140.

Hereinafter, it is to be understood that the HSS and UDM may be integrated in a same network entity or may be separated with each other, and the IMS AS and DSCF may be integrated in a same network entity or may be separated with each other.

The signaling flow 200 in FIG. 2 refers to a scenario in which authorization and privacy protection for IMS DC event exposure may be based on subscription-based DC authorization policy. In this scenario, as an example, DC authorization policies may be provisioned in HSS/UDM based on subscription contract, privacy policies may be preconfigured in NEF or PCF/PCRF/UDM/HSS, and user consent is preconfigured in UDM/HSS.

It is to be understood that the term “aDC authorization policy” , “the DC authorization policy” , “DC authorization policies” and/or “one or more DC authorization policies” used hereinafter may be considered as a DC specific authorization policy for the DC communication in IMS DC. In this scenario, the one or more DC authorization policies comprises at least one subscription-based DC authorization policy.

As shown in FIG. 2, the NEF 110 receives (202) a request of a DC communication service, e.g., a DC event subscription, from DC AS 140.

In option 1, the NEF 110 may determine whether the request of the service associated with the DC communication is allowed based on one or more DC authorization policies retrieved from the at least one network function, e.g., from HSS/UDM 120. It is to be understood that the one or more DC authorization policies may also be retrieved from other network function such as PCF, PCRF, IMS AS/DCSF 130.

As shown in FIG. 2, the NEF 110 may request to retrieve (204) one or more DC authorization policies and corresponding user consent retrieved from HSS/UDM 120 and obtain the requested one or more DC authorization policies and corresponding user consent from HSS/UDM 120. If the NEF 110 determines, based on the one or more DC authorization policies and/or the corresponding user consent retrieved from the HSS/UDM 120, that the request of the service associated with the DC communication is authorized, the NEF 110 may determine that the service is to be exposed to the DC application server.

That is, one or more DC authorization policies and/or the corresponding user consent are used for the NEF 110 to authorize the request from the DC AS 140.

For example, the NEF 110 retrieves authorization policies and user consent from HSS/UDM 120 based on at least a UE ID in the request and makes authorization decision and grants permission for the request based on the policies and user consent.

In option 2, the NEF 110 may determine whether the request of the service associated with the DC communication is allowed based on an authorization decision received from at least one network function e.g., from HSS/UDM 120.

As shown in FIG. 2, the NEF 110 may transmit (206) related information extracted from the request of the service associated with the DC communication. If the NEF 110 receives an indication indicating the request is authorized, the NEF 110 may determine that the service associated with the DC communication is to be exposed to the DC application server.

For example, the NEF 110 extracts required information from the request and sends the information to HSS/UDM 120 for authorization. Then the NEF 110 may accept the request if get grant from HSS/UDM 120. That is, in option 2, HSS/UDM 120 performs the authorization check.

For both options 1 and 2, if an application function (AF) (e.g., associated with the DC AS 140) is requesting DC event for any/All UEs (or group of UEs) , then before passing the event of a UE from 5G Core network to AF, the NEF 110 may check the authorization policy and consent flag for the UE. If policy and consent are allowed, then only provide the data or block the data.

After determining the request of the service associated with the DC communication is allowed, for both options 1 and 2, the NEF 110 sends (208) the DC event subscription request to IMS AS/DSCF 130 indicating that the request of the service associated with the DC communication is allowed. Then the NEF 110 may receive (212) response from IMS AS/DSCF 130.

The NEF 110 may transmit (214) a response to the DC AS 140 indicating that the service request associated with the DC communication is proceeded.

After that, the NEF 110 may receive (216) a DC event notification from a network function, e.g., an IMS AS/DSCF 130. If the NEF 110 determines a DC event notification is received from the IMS AS/DSCF 130, the NEF 110 may retrieve (218) DC AS property and one or more privacy policies from the locally or the at least one network function, such as PCF/PCRF/UDM/HSS/DCSF. The NEF 110 may anonymize (220) the DC event data based on the DC application server property and the one or more privacy policies and transmit (222) the anonymized DC event data as a part of notification to the DC application server. More specifically, the NEF 110 may anonymize personal data in the notification if required according to privacy policy and AF properties.

In addition to options 1 and 2 described above, in option 3, whether the request of the service associated with the DC communication is allowed may be determined by the IMS AS/DSCF 130. That is, the IMS AS/DSCF 130 may make authorization decision and grant permission for the request.

As shown in FIG. 2, after receiving the request of a service associated with a DC communication in IMS to the IMS AS/DSCF 130 the NEF 110 may forward (208) the request to the IMS AS/DSCF 130.

The IMS AS/DSCF 130 may request to retrieve (210) one or more DC authorization policies and corresponding user consent retrieved from HSS/UDM 120 and obtain the requested one or more DC authorization policies and corresponding user consent from HSS/UDM 120. If the IMS AS/DSCF 130 determines, based on the one or more DC authorization policies and/or the corresponding user consent retrieved from the HSS/UDM 120, that the request of the service associated with the DC communication is authorized, the IMS AS/DSCF 130 may determine that the service is to be exposed to the DC application server.

That is, one or more DC authorization policies and/or the corresponding user consent are used for the IMS AS/DSCF 130 to authorize the request from the DC AS 140. It is to be understood that the one or more DC authorization policies may also be retrieved from other network function such as PCF or PCRF.

It is also possible that the IMS AS/DSCF 130 may determine whether the request of the service associated with the DC communication is allowed based on based on an authorization decision received from at least one network function e.g., from HSS/UDM 120.

For example, the IMS AS/DSCF 130 may transmit related information extracted from the request of the service associated with the DC communication. If the IMS AS/DSCF 130 receives an indication indicating the request is authorized, the IMS AS/DSCF 130 may determine that the service associated with the DC communication is to be exposed to the DC application server.

Then the NEF 110 may receive (212) response from IMS AS/DSCF 130 indicating that the service associated with the DC communication is authorized to be exposed to the DC AS 140.

Other actions in the option 3 are similar with actions 214-222 described with reference to options 1 and 2, which may be omitted here.

In this scenario, if the AF property is for operator administration, and the privacy policy allows IMS system to collect and proceed subscriber information, such as, caller and called telephone number, downloading/downloaded applications, establishing/established application DCs, together with location and time etc., NEF 110 may expose all information to the AF as raw data.

If AF property is for operator or 3rd party statistics and advertisement, and the privacy policy allows IMS system to collect and proceed subscriber information, but the policy doesn't allow IMS system to share the raw data for non-admission purpose, NEF 110 may mask calling and called number, but still share downloaded applications, in specific region and/or period.

If AF property shows its application client on UE on behalf of the subscriber, all DC related information collected by IMS system for the subscriber can be exposed to the AF to allow the user to monitor the status of application DC.

It is to be understood that the privacy policy can be part of user consent.

The reference now is made to FIG. 3, which illustrates a signaling flow 300 of communication in accordance with some embodiments of the present disclosure. For the purposes of discussion, the signaling flow 300 will be discussed with reference to FIG. 1, for example, by using the NEF 110, the HSS/UDM 120, the IMS AS/DSCF 130 and DC AS 140.

The signaling flow 300 in FIG. 3 refers to a scenario in which authorization and privacy protection for IMS DC event exposure may be based on AF-based authorization policy. In this scenario, as an example, DC authorization policies may be provisioned in NEF/PCF/PCRF/DCSF/IMS AS according to operator's polices, privacy policies may be preconfigured in NEF or PCF/PCRF/UDM/HSS and user consent specific to IMS DC is preconfigured in UDM/HSS.

It is to be understood that the term “aDC authorization policy” , “the DC authorization policy” , “DC authorization policies” and/or “one or more DC authorization policies” used hereinafter may be considered as a DC specific authorization policy for the DC communication in IMS DC. In this scenario, the one or more DC authorization policies comprises at least one application function-based DC authorization policies.

As shown in FIG. 3, the NEF 110 receives (302) a request of a DC communication service, e.g., a DC event subscription, from the DC AS 140.

As shown in FIG. 3, for determining whether the request of the service associated with the DC communication is allowed, the NEF 110 may retrieve (304) one or more DC authorization policies locally or from the at least one network function, e.g., from HSS/UDM 120. It is to be understood that the one or more DC authorization policies may also be retrieved from other network function such as PCF, PCRF, IMS AS/DCSF 130.

The NEF 110 may retrieve (306) user consent specific to IMS DC retrieved from HSS/UDM 120. Based on the one or more DC authorization policies and/or the corresponding user consent retrieved from the HSS/UDM 120, the NEF 110 may determine whether the request of the service associated with the DC communication is authorized. If so, the NEF 110 may determine (308) that the service is to be exposed to the DC application server.

After determining the request of the service associated with the DC communication is allowed, the NEF 110 sends (310) the DC event subscription request to IMS AS/DSCF 130 indicating that the request of the service associated with the DC communication is allowed. Then the NEF 110 may receive (314) response from IMS AS/DSCF 130.

The NEF 110 may transmit (316) a response the DC AS 140 indicating that the service request associated with the DC communication is proceeded.

After that, the NEF 110 may receive (318) DC event notification from a network function, e.g., an IMS AS/DSCF 130. If the NEF 110 determines a DC event notification is received from the IMS AS/DSCF 130, the NEF 110 may retrieve (320) DC AS property and one or more privacy policies from the locally or the at least one network function, such as PCF/PCRF/UDM/HSS/DCSF. The NEF 110 may anonymize (322) the DC event data based on the DC application server property and the one or more privacy policies and transmit (324) the anonymized DC event data as a part of notification to the DC application server. More specifically, the NEF 110 may anonymize personal data in the notification if required according to privacy policy and AF properties.

It is to be understood that the operation (s) performed by the NEF 110 in the scenario shown in FIG. 3 may also be performed by the IMS AS/DCSF 130. For example, authorization and anonymization can be also done by the IMS AS/DCSF 130 instead of NEF 110. Similarly with the scenario shown in FIG. 2, the privacy policy can be part of user consent.

The reference now is made to FIG. 4, which illustrates a signaling flow 400 of communication in accordance with some embodiments of the present disclosure. For the purposes of discussion, the signaling flow 400 will be discussed with reference to FIG. 1, for example, by using the NEF 110, the HSS/UDM 120, the IMS AS/DSCF 130 and DC AS 140.

The signaling flow 400 in FIG. 4 refers to a scenario of authorization for IMS DC session control exposure for application DC (ADC) initiation/update/release. Hereinafter, DC initiation/update/release may be referred to as DC session control.

It is to be understood that the term “a DC authorization policy” , “the DC authorization policy” , “DC authorization policies” and/or “one or more DC authorization policies” used hereinafter may be considered as a DC specific authorization policy for the DC communication in IMS DC. MS

As shown in FIG. 4, the NEF 110 receives (402) a request of a DC communication service, e.g., a DC session control, from DC AS 140.

The NEF 110 may retrieve (404) one or more DC authorization policies locally or from the at least one network function, e.g., from HSS/UDM 120. It is to be understood that the one or more DC authorization policies may also be retrieved from other network function such as PCF, PCRF, IMS AS/DCSF 130.

Based on the one or more DC authorization policies, the NEF 110 may check (406) if the DC application server is matched to an application corresponding to a target application DC associated with the service based on the one or more DC authorization policies.

If the NEF 110 determines that the DC application server is matched to the application corresponding to the target application DC, the NEF 110 may determine (408) that the DC session control is allowed. For example, If the DC AS is matched to the application associated to the target application DC and it's allowed to perform the required control/operation on the application DC based on the authorization policies, the NEF 110 may grant permission for the request.

Then the NEF 110 may send (410) ADC session control request to the IMS AS/DSCF 130 and receive (412) a response from the IMS AS/DSCF 130. Then the NEF 110 may forward (414) the response to the DC AS 140.

It is to be understood that, in addition to the retrieving of the one or more DC authorization policies locally or from the at least one network function, the actions described above may also be used for a scenario of authorization for IMS DC session control exposure for bootstrap DC (BDC) create/terminate/update or application download, which may also be referred to as DC session control. Subscription based user consent may not be needed in this scenario if no personal data will be exposed.

Similarly, the operation (s) performed by the NEF 110 in the scenario shown in FIG. 4 may also be performed by IMS AS/DCSF 130. This procedure is referred to scenario of AF-based authorization policy, it may be applicable to scenario of subscription-based authorization policy with adopting corresponding steps. In subscription-based authorization policy case, if UE Id is not included in the request, NEF 110 may get UE Id from DCSF/IMS AS according to other identity in the request, such as session Id, DC Id, etc.

In summary, the solution of the present disclosure proposes a mechanism for authorizing the AF/AS based on authorization policies when an AF/AS access IMS data DC services. It is to be understood that the solution of the present disclosure may also be reused for non-DC IMS service exposure protection, in that case, the authorization policies are DC agnostic.

The authorization policies may include subject, allowed services, i.e., operation and resource, and conditions, e.g., location, time, specific subscriber for AF-based policies.

The subject may refer to, e.g., application function/server (identified by AF/AS ID, optionally with AF type for subscription-based polices) .

The allowed services may refer to, e.g., subscribe (for event) and event resource (e.g. event type, linked DC/Media session, etc. ) and establish/terminate/update/download and target resource (e.g. resource type (application DC, bootstrap DC, application, media session, etc. ) , resource instance (e.g. DC Id, app Id, session Id, or URI to represent Restful resource) .

The conditions may refer to, e.g., location: if subscriber is in certain location, then only AF is allowed to access the event; and time or time duration: Only in certain time duration, events are exposed to AF.

Furthermore, protect personal/privacy data based on privacy policies and user consent when send IMS DC event to an AF/AS.

The privacy policies may include policy to exclude or anonymize personal data when send event, e.g., what personal data should be excluded in every event; what personal data can be included in the event but anonymized based on AF property; what raw personal data can be included in the event based on AF property.

Examples of DC authorization policy and privacy policy are shown in Table 1 and Table 2.

Table 1

Table 2

It is to be understood that privacy data may be, e.g. caller and called id, downloaded applications, time create/terminate DC, etc. and the AF property may be, e.g. operator AF, 3rd party AF on behalf of subscriber (e.g. for session control) , 3rd party AF for application usage or performance analytics/survey/statistic, etc.

FIG. 5 shows a flowchart of an example method 500 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 500 will be described from the perspective of the NEF 110 or the IMS AS/DCSF 130 in FIG. 1.

At block 510, the NEF or the IMS AS/DCSF receives a request of a service associated with a DC communication in an IMS.

At block 520, the NEF or the IMS AS/DCSF determines whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function.

At block 530, the NEF or the IMS AS/DCSF causes, based on the determination, the service associated with the DC communication to be exposed to a DC application server.

In some example embodiments, the method 500 further comprises: in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, transmitting to the at least one network function, a request for retrieving at least one of the following: one or more DC authorization policies, or corresponding user consent; and in accordance with the determination, based on the one or more DC authorization policies and/or the corresponding user consent retrieved from the at least one network function, that the request is authorized, determine that the service is to be exposed to the DC application server.

In some example embodiments, the method 500 further comprises: in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, transmitting to the at least one network function, information extracted from the request; and in accordance with the determination that an indication received from the at least one network function indicating the request is authorized, determining that the service associated with the DC communication is to be exposed to the DC application server.

In some example embodiments, the method 500 further comprises: in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, forwarding the request to an IMS application server or a data channel signaling function, DCSF; and in accordance with a determination that a response to the request indicating that the service associated with the DC communication is allowed to be exposed to the DC application server, determining that the service associated with the DC communication is to be exposed to the DC application server.

In some example embodiments, the method 500 further comprises: transmitting, to the DC application server, a response indicating that the service request associated with the DC communication is proceeded.

In some example embodiments, the service associated with the DC communication comprises a service of a DC event subscription, and wherein the method 500 further comprises: in accordance with the determination that a DC event notification , retrieving DC application server property and one or more privacy policies from the apparatus or the at least one network function; anonymizing the DC event data based on the DC application server property and the one or more privacy policies; and transmitting the anonymized DC event data as a part of notification to the DC application server.

In some example embodiments, the service associated with the DC communication comprises a DC session control, and wherein the method 500 further comprises: checking if the DC application server is matched to an application corresponding to a target application DC associated with the service based on the one or more DC authorization policies; and in accordance with the determination that the DC application server is matched to the application corresponding to the target application DC, determining that the DC session control is allowed.

In some example embodiments, the method 500 further comprises: in accordance with the determination that the request of the service associated with the DC communication is received from a Network Exposure Function, NEF, transmitting, to the at least one network function, information extracted from the request; and in accordance with the determination that an indication received from the at least one network function indicating the request is authorized, transmitting a response to the request indicating that the service associated with the DC communication is allowed to be exposed to the DC application server.

In some example embodiments, the service associated with the DC communication comprises at least one of the following: a DC event subscription, a DC initiation, a DC release, a DC communication update, or a DC download.

In some example embodiments, the at least one function comprises at least one of the following: a policy control function, PCF, a policy and charging rules function, PCRF, a unified data management, UDM, a home subscriber server, HSS, a DCSF, or an IMS application server, IMS AS.

In some example embodiments, the one or more DC authorization policies comprises at least one subscription-based DC authorization policy and/or at least one application function-based DC authorization policies.

In some example embodiments, the apparatus comprises an NEF or an IMS AS or a DCSF.

FIG. 6 shows a flowchart of an example method 600 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the UDM/HSS 120 in FIG. 1.

At block 610, the UDM/HSS 120 receives, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a DC communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service.

At block 620, the UDM/HSS 120 transmits, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.

In some example embodiments, the method 600 further comprises: obtaining the one or more DC authorization policies from the apparatus or at least one further network function; and determining whether the request of the service is authorized based on the one or more DC authorization policies.

In some example embodiments, the method 600 further comprises: in accordance with the determination that the request is received from the NEF, or an IMS AS or a DCSF for retrieving the one or more DC authorization policies and corresponding user consent, transmitting the one or more DC authorization policies and corresponding user consent to the NEF.

In some example embodiments, the at least one function comprises at least one of the following: a PCF, a PCRF, a DCSF, or an IMS AS.

In some example embodiments, the apparatus comprises a UDM or an HSS.

In some example embodiments, an apparatus capable of performing any of the method 500 (for example, the NEF 110 or the IMS AS/DCSF 130 in FIG. 1) may comprise means for performing the respective operations of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the NEF 110 or the IMS AS/DCSF 130 in FIG. 1.

In some example embodiments, the apparatus comprises means for receiving a request of a service associated with a DC communication in an IMS; means for determining whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and means for causing, based on the determination, the service associated with the DC communication to be exposed to a DC application server.

In some example embodiments, the apparatus is caused to: means for in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, transmitting to the at least one network function, a request for retrieving at least one of the following: one or more DC authorization policies, or corresponding user consent; and means for in accordance with the determination, means for determining on the one or more DC authorization policies and/or the corresponding user consent retrieved from the at least one network function, that the request is authorized, determine that the service is to be exposed to the DC application server.

In some example embodiments, the apparatus is caused to: means for in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, transmitting to the at least one network function, information extracted from the request; and means for in accordance with the determination that an indication received from the at least one network function indicating the request is authorized, determining that the service associated with the DC communication is to be exposed to the DC application server.

In some example embodiments, the apparatus is caused to: means for in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, forwarding the request to an IMS application server or a data channel signaling function, DCSF; and means for in accordance with a determination that a response to the request indicating that the service associated with the DC communication is allowed to be exposed to the DC application server, determining that the service associated with the DC communication is to be exposed to the DC application server.

In some example embodiments, the apparatus is caused to: means for transmitting, to the DC application server, a response indicating that the service request associated with the DC communication is proceeded.

In some example embodiments, the service associated with the DC communication comprises a service of a DC event subscription, and wherein the apparatus is caused to: means for in accordance with the determination that a DC event notification , retrieving DC application server property and one or more privacy policies from the apparatus or the at least one network function; means for anonymizing the DC event data based on the DC application server property and the one or more privacy policies; and means for transmitting the anonymized DC event data as a part of notification to the DC application server.

In some example embodiments, the service associated with the DC communication comprises a DC session control, and wherein the apparatus is caused to: means for checking if the DC application server is matched to an application corresponding to a target application DC associated with the service based on the one or more DC authorization policies; and means for in accordance with the determination that the DC application server is matched to the application corresponding to the target application DC, determining that the DC session control is allowed.

In some example embodiments, the apparatus is caused to: means for in accordance with the determination that the request of the service associated with the DC communication is received from a Network Exposure Function, NEF, transmitting, to the at least one network function, information extracted from the request; and means for in accordance with the determination that an indication received from the at least one network function indicating the request is authorized, transmitting a response to the request indicating that the service associated with the DC communication is allowed to be exposed to the DC application server.

In some example embodiments, an apparatus capable of performing any of the method 600 (for example, the HSS/UDM 120 in FIG. 1) may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the HSS/UDM 120 in FIG. 1.

In some example embodiments, the apparatus comprises means for receiving, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a DC communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and means for transmitting, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.

In some example embodiments, the apparatus is caused to: means for obtaining the one or more DC authorization policies from the apparatus or at least one further network function; and means for determining whether the request of the service is authorized based on the one or more DC authorization policies.

In some example embodiments, the apparatus is caused to: means for in accordance with the determination that the request is received from the NEF, or an IMS AS or a DCSF for retrieving the one or more DC authorization policies and corresponding user consent, transmitting the one or more DC authorization policies and corresponding user consent to the NEF.

In some example embodiments, the apparatus comprises a UDM or an HSS.

FIG. 7 is a simplified block diagram of a device 700 that is suitable for implementing example embodiments of the present disclosure. The device 700 may be provided to implement a communication device, for example, the NEF 110 or the IMS AS/DCSF 130 or the UDM/HSS 120 as shown in FIG. 1. As shown, the device 700 includes one or more processors 710, one or more memories 720 coupled to the processor 710, and one or more communication modules 740 coupled to the processor 710.

The communication module 740 is for bidirectional communications. The communication module 740 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 740 may include at least one antenna.

The processor 710 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 700 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

The memory 720 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 724, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 722 and other volatile memories that will not last in the power-down duration.

A computer program 730 includes computer executable instructions that are executed by the associated processor 710. The instructions of the program 730 may include instructions for performing operations/acts of some example embodiments of the present disclosure. The program 730 may be stored in the memory, e.g., the ROM 724. The processor 710 may perform any suitable actions and processing by loading the program 730 into the RAM 722.

The example embodiments of the present disclosure may be implemented by means of the program 730 so that the device 700 may perform any process of the disclosure as discussed with reference to FIG. 2 to FIG. 6. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some example embodiments, the program 730 may be tangibly contained in a computer readable medium which may be included in the device 700 (such as in the memory 720) or other storage devices that are accessible by the device 700. The device 700 may load the program 730 from the computer readable medium to the RAM 722 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

FIG. 8 shows an example of the computer readable medium 800 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 800 has the program 730 stored thereon.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

An apparatus comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:

receive a request of a service associated with a data channel, DC, communication in an internet protocol multimedia subsystem, IMS;

determine whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and

cause, based on the determination, the service associated with the DC communication to be exposed to a DC application server.
The apparatus of claim 1, wherein the apparatus is caused to:

in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, transmit, to the at least one network function, a request for retrieving at least one of the following:

the one or more DC authorization policies, or

corresponding user consent; and

in accordance with the determination, based on the one or more DC authorization policies and/or the corresponding user consent retrieved from the at least one network function, that the request is authorized, determine that the service is to be exposed to the DC application server.
The apparatus of claim 1, wherein the apparatus is caused to:

in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, transmit, to the at least one network function, information extracted from the request; and

in accordance with the determination that an indication received from the at least one network function indicating the request is authorized, determine that the service associated with the DC communication is to be exposed to the DC application server.
The apparatus of claim 1, wherein the apparatus is caused to:

in accordance with the determination that the request of the service associated with the DC communication is received from the DC application server, forward the request to an IMS application server or a data channel signaling function, DCSF; and

in accordance with a determination that a response to the request indicating that the service associated with the DC communication is allowed to be exposed to the DC application server, determine that the service associated with the DC communication is to be exposed to the DC application server.
The apparatus of any of claim 2-4, wherein the apparatus is caused to:

transmit, to the DC application server, a response indicating that the service request associated with the DC communication is proceeded.
The apparatus of claim any of claims 2-4, wherein the service associated with the DC communication comprises a service of a DC event subscription, and wherein the apparatus is caused to:

in accordance with the determination that a DC event notification retrieves DC application server property and one or more privacy policies from the apparatus or the at least one network function;

anonymize the DC event data based on the DC application server property and the one or more privacy policies; and

transmit the anonymized DC event data as a part of notification to the DC application server.
The apparatus of claim 2, wherein the service associated with the DC communication comprises a DC session control, and wherein the apparatus is caused to:

check if the DC application server is matched to an application corresponding to a target application DC associated with the service based on the one or more DC authorization policies; and

in accordance with the determination that the DC application server is matched to the application corresponding to the target application DC, determine that the DC session control is allowed.
The apparatus of claim 1, wherein the apparatus is caused to:

in accordance with the determination that the request of the service associated with the DC communication is received from a Network Exposure Function, NEF, transmit, to the at least one network function, information extracted from the request; and

in accordance with the determination that an indication received from the at least one network function indicating the request is authorized, transmit, a response to the request indicating that the service associated with the DC communication is allowed to be exposed to the DC application server.
The apparatus of any of claims 1-8, wherein the service associated with the DC communication comprises at least one of the following:

a DC event subscription,

a DC initiation,

a DC release,

a DC communication update, or

a DC download.
The apparatus of any of claims 1-9, wherein the at least one function comprises at least one of the following:

a policy control function, PCF,

a policy and charging rules function, PCRF,

a unified data management, UDM,

a home subscriber server, HSS,

a DCSF, or

an IMS application server, IMS AS.
The apparatus of any of claims 1-10, wherein the one or more DC authorization policies comprises at least one subscription-based DC authorization policy and/or at least one application function-based DC authorization policies.
The apparatus of any of claims 1-11, wherein the apparatus comprises an NEF or an IMS AS or a DCSF.
An apparatus comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:

receive, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a data channel, DC, communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and

transmit, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.
The apparatus of claim 13, wherein the apparatus is caused to:

obtain the one or more DC authorization policies from the apparatus or at least one further network function; and

determine whether the request of the service is authorized based on the one or more DC authorization policies.
The apparatus of claim 13, wherein the apparatus is caused to:

in accordance with the determination that the request is received from the NEF, or an IMS AS or a DCSF for retrieving the one or more DC authorization policies and corresponding user consent, transmit the one or more DC authorization policies and corresponding user consent to the NEF.
The apparatus of any of claims 13-15, wherein the service associated with the DC communication comprises at least one of the following:

a DC event subscription,

a DC initiation,

a DC release,

a DC communication update, or

a DC application download.
The apparatus of any of claims 13-16, wherein the at least one function comprises at least one of the following:

a PCF,

a PCRF,

a DCSF, or

an IMS AS.
The apparatus of any of claims 13-17, wherein the one or more DC authorization policies comprises at least one subscription-based DC authorization policy and/or at least one application function-based DC authorization policies.
The apparatus of any of claims 1-11, wherein the apparatus comprises a UDM or an HSS.
A method comprising:

receiving a request of a service associated with a data channel, DC, communication in an internet protocol multimedia subsystem, IMS;

determining whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function;

causing, based on the determination, the service associated with the DC communication to be exposed to a DC application server.
A method comprising:

receiving, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a data channel, DC, communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and

transmitting, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.
A first apparatus comprising:

means for receiving a request of a service associated with a data channel, DC, communication in an internet protocol multimedia subsystem, IMS;

means for determining whether the request of the service associated with the DC communication is allowed at least based on an authorization decision received from at least one network function or one or more DC authorization policies retrieved from the at least one network function; and

means for causing, based on the determination, the service associated with the DC communication to be exposed to a DC application server.
A apparatus comprising:

means for receiving, from one of a NEF or an IMS AS or a DCSF, information associated with a request of a service associated with a data channel, DC, communication in an IMS or a request for retrieving at least one or more DC authorization policies corresponding to the request of the service; and

means for transmitting, to one of the NEF or the IMS AS or the DCSF, an indication indicating whether the request of the service is authorized or the one or more DC authorization policies.
A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of claim 20 or the method of claim 21.