Supporting a network initiated IMS data channel

Abstract

Embodiments herein provide a method and a system for supporting a network initiated IMS data channel (DC). The method includes receiving a request from a third party network apparatus (202) to add or remove an IMS DC to an existing IMS session established between a first UE (402A) and a second UE (402B). Further, determining whether the first UE (402A) has a capability for the IMS DC based on a stored UE context and a user subscription information received from a home subscriber server (HSS) (408). Further, generating a session event control notify request message to be transmitted to a DCSF (302) when the first UE (402A) has the capability for the IMS DC and is authorized to use the IMS DC. In addition, receiving a media control request message from the DCSF (302) including instructions to add or remove the IMS DC to the existing IMS session established.

Description

SUPPORTING A NETWORK INITIATED IMS DATA CHANNEL

[0001] The present disclosure is related to the field of IP Multimedia Subsystem (IMS) in 3GPP. More particularly, the present disclosure is related to a method and system for supporting a network initiated IMS data channel (DC).

[0002]

[0003] The IP Multimedia Subsystem (IMS) has been in existence for a considerable time, with nearly all major operators having implemented their networks to deliver a range of services, including the widely utilized Voice over LTE (VoLTE) service. Currently, IMS is evolving to meet the demands of 5G verticals, enabling the introduction of various new services that leverage the IMS Data Channel alongside traditional voice and video calls. This IMS Data Channel will facilitate numerous applications such as Remote Support, Remote Surgery, and Remote Examination, augmented reality with control, machine control, and virtual reality with collaboration. The GSMA NG UPG#08 has recognized the necessity for network-initiated IMS Data Channel mid-call setups in specific scenarios. For instance, when a customer contacts a retailer's Sales Support or Customer Care, the service representative or an automated Interactive Voice Response (IVR) system may need to initiate an interactive menu during the call. In these instances, the User Equipment (UE) is not pre-configured to initiate the IMS Data Channel, making network-initiated capabilities essential for supporting UEs. The current 23.228 clause AC.7.1 outlines that a Re-INVITE for mid-call IMS Data Channel addition is permissible, but further clarification may be required for network-initiated Re-INVITE. The GSMA anticipates that this use case will be commonly encountered in Business-to-Consumer (B2C) scenarios, and the support for this capability could be pivotal in the initial deployment decisions for the IMS Data Channel.

[0004] In Release 18, 3GPP SA2 has introduced a solution exclusively for the originating User Equipment (UE) that initiates the IMS Data Channel (DC) alongside other media types, including audio and video. This is achieved by providing an SDP with an 'm' line for IMS DC, audio, video, and so forth, or by upgrading an existing audio or video call to an IMS DC call by incorporating an 'm' line for IMS DC. However, the specification has yet to address a scenario in which the network can upgrade an already established call to an IMS DC call.

[0005] Hence, it is desirable to address the above mentioned problems and disadvantages or at least provide a useful alternative.

[0006]

[0007] The principal object of the embodiments herein is to provide a system and method of ensuring that IMS network is able to support IMS DC for an already established IMS session.

[0008]

[0009] In one aspect, the objectives are achieved by providing a method for supporting a network initiated IMS data channel (DC). The method includes receiving a request by IMS Application server (IMS AS) from a third party network apparatus to add or remove an IMS DC to an existing IMS session established between a first UE and a second UE. Further, the method includes determining by IMS AS whether the first UE has a capability for the IMS DC based on a stored UE context and a user subscription information received from a home subscriber server (HSS) indicating whether the first UE is authorized to use the IMS DC. Further, the method includes generating a session event control notify request message to be transmitted to a data channel signalling function (DCSF) by updating the existing IMS session as received from the third party network apparatus. The session event control notify request message is generated when the first UE has the capability for the IMS DC and when the first UE is authorized to use the IMS DC. In addition, the method includes receiving by IMS AS a media control request message from the DCSF that comprises instructions to add or remove the IMS DC to the existing IMS session established and to allocate media resources for the existing IMS session when the first UE has the capability for the IMS DC and when the first UE is authorized to use the IMS DC.

[0010] In an embodiment, the third party network apparatus comprises at least one of an trusted application function (AF), an untrusted AF, and a data channel application server (DCAS).

[0011] In an embodiment, the request comprises updating or adding the IMS DC to at least one of an established audio call or an established video call of the existing IMS session.

[0012] In an embodiment, the request comprises adding or removing bootstrap data channels or application data channels in the existing IMS session.

[0013] In an embodiment, the method includes generating a reject request to be transmitted to the third party network apparatus to add or remove the IMS DC to the existing IMS session established, when the first UE does not have the capability for the IMS DC and is not authorized to use the IMS DC.

[0014] In an embodiment, the method includes generating a re-INVITE request message to be transmitted to the first UE, wherein the re-INVITE request message comprises a session description protocol (SDP) that includes media information of the IMS DC required by the third party network apparatus.

[0015] In an embodiment, the re-INVITE request message enables updating or adding the IMS DC to at least one of an established audio call or an established video call of the existing IMS session.

[0016] In one aspect, the objectives are achieved by providing a method for supporting a network initiated IMS DC. The method includes generating a request to be transmitted to an IMS AS, wherein the request provides an indication to add or remove an IMS DC to an existing IMS session established between a first UE and a second UE. Further, the method includes determining whether to add or remove the IMS DC to the existing IMS session based on a local policy or an event notification of the existing IMS Session that the third party network apparatus subscribes to. In addition, the method includes generating a session management update request message to be transmitted to a NEF(network exposure function) based on the local policy or the event notification of the existing IMS Session. The session management update request message adds or removes bootstrap data channels or application data channels in the existing IMS session.

[0017] In one aspect, the objectives are achieved by providing a method for supporting a network initiated IMS DC. The method includes receiving a session event control notify request message from an IMS AS. The session event control notify request message indicates that a first UE has a capability for an IMS DC and is authorized to use the IMS DC based on subscription information from a HSS indicating whether the first UE is authorized to use the IMS DC. In addition, the method includes generating a media control request message to be transmitted to the IMS AS upon receiving the session event control notify request message. The media control request message comprises instructions to add or remove the IMS DC to the existing IMS session established between the first UE and a second UE.

[0018] In one aspect, the objectives are achieved by providing an IMS AS for supporting a network initiated IMS DC. The IMS AS includes a processor, a memory coupled to the processor, and a first controller communicatively coupled to the memory and the processor. The first controller receives a request from a third party network apparatus to add or remove an IMS DC to an existing IMS session established between a first UE and a second UE. Further, the first controller determines whether the first UE has a capability for the IMS DC based on a stored UE context and a user subscription information received from a home subscriber server (HSS) indicating whether the first UE is authorized to use the IMS DC. Further, the first controller generates a session event control notify request message to be transmitted to a data channel signalling function (DCSF) by updating the existing IMS session as received from the third party network apparatus. The session event control notify request message is generated when the first UE has the capability for the IMS DC and when the first UE is authorized to use the IMS DC. In addition, the first controller receives a media control request message from the DCSF that comprises instructions to add or remove the IMS DC to the existing IMS session established and to allocate media resources for the existing IMS session when the first UE has the capability for the IMS DC and when the first UE is authorized to use the IMS DC.

[0019] In an embodiment, the request comprises updating or adding the IMS DC to at least one of an established audio call or an established video call of the existing IMS session.

[0020] In an embodiment, the request comprises adding or removing bootstrap data channels or application data channels in the existing IMS session.

[0021] In an embodiment, the first controller generates a reject request to be transmitted to the third party network apparatus to add or remove the IMS DC to the existing IMS session established, when the first UE does not have the capability for the IMS DC and is not authorized to use the IMS DC.

[0022] In an embodiment, the first controller generates a re-INVITE request message to be transmitted to the first UE, wherein the re-INVITE request message comprises a session description protocol (SDP) that includes media information of the IMS DC required by the third party network apparatus.

[0023] In an embodiment, the re-INVITE request message enables updating or adding the IMS DC to at least one of an established audio call or an established video call of the existing IMS session.

[0024] In one aspect, the objectives are achieved by providing a third party network apparatus for supporting a network initiated IMS DC. The third party network apparatus includes a first processor, a first memory coupled to the first processor, and a second controller communicatively coupled to the first memory and the first processor. The second controller generates a request to be transmitted to an IMS AS, wherein the request provides an indication to add or remove an IMS DC to an existing IMS session established between a first UE and a second UE. Further, the second controller determines whether to add or remove the IMS DC to the existing IMS session based on a local policy or an event notification of the existing IMS Session that the third party network apparatus subscribes to. In addition, the second controller generates a session management update request message to be transmitted to a NEF based on the local policy or the event notification of the existing IMS Session. The session management update request message adds or removes bootstrap data channels or application data channels in the existing IMS session.

[0025] In one aspect, the objectives are achieved by providing a DCSF for supporting a network initiated IMS DC. The DCSF includes a second processor, a second memory coupled to the second processor, and a third controller communicatively coupled to the second memory and the second processor. The third controller receives a session event control notify request message from an IMS AS. The session event control notify request message indicates that a first UE has a capability for an IMS DC and is authorized to use the IMS DC. In addition, the third controller generates a media control request message to be transmitted to the IMS AS upon receiving the session event control notify request message. The media control request message comprises instructions to add or remove the IMS DC to the existing IMS session established between the first UE and a second UE.

[0026] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications be made within the scope of the embodiments herein.

[0027]

[0028] According to an example of the present disclosure, IMS (IP multimedia subsystem) network is capable of supporting an IMS data channel (DC) for an established IMS session between a terminal and another terminal.

[0029] In addition, the IMS network can add or remove an IMS DC on the established IMS session in scenarios where the terminal needs to interact with the another terminal, even if the terminal is not preconfigured to initialize the IMS DC.

[0030]

[0031] These and other features, aspects, and advantages of the present embodiments are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0032] Figure 1 is a block diagram that illustrates a schematic of an IMS AS implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0033] Figure 2 is a block diagram that illustrates a schematic of a third party network apparatus implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0034] Figure 3 is a block diagram that illustrates a schematic of a DCSF implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0035] Figure 4 is a sequence diagram that illustrates a scenario network initiated IMS DC procedure according to an embodiment as disclosed herein.

[0036] Figure 5 is a flow diagram that illustrates a method for supporting a network initiated IMS DC by the IMS AS according to an embodiment as disclosed herein.

[0037] Figure 6 is a flow diagram that illustrates a method for supporting a network initiated IMS DC by the third party network apparatus according to an embodiment as disclosed herein.

[0038] Figure 7 is a flow diagram that illustrates a method for supporting a network initiated IMS DC by the DCSF according to an embodiment as disclosed herein.

[0039] It may be noted that to the extent possible, like reference numerals have been used to represent like elements in the drawing. Further, those of ordinary skill in the art will appreciate that elements in the drawing are illustrated for simplicity and may not have been necessarily drawn to scale. For example, the dimension of some of the elements in the drawing may be exaggerated relative to other elements to help to improve the understanding of aspects of the invention. Furthermore, the elements may have been represented in the drawing by conventional symbols, and the drawings may show only those specific details that are pertinent to the understanding the embodiments of the invention so as not to obscure the drawing with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

[0040]

[0041] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with a plurality of other embodiments to form new embodiments. The term "or" as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples are not be construed as limiting the scope of the embodiments herein.

[0042] As is traditional in the field, embodiments are described and illustrated in terms of blocks that carry out a described function or functions.　These blocks, which referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, and the like, and optionally be driven by firmware and software. The circuits, for example, be embodied in a plurality of semiconductor chips, or on substrate supports such as printed circuit boards, and the like.　The circuits constituting a block be implemented by dedicated hardware, or by a processor (e.g., a plurality of programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments be physically separated into two or more interacting and discrete blocks without departing from the scope of the proposed method.　Likewise, the blocks of the embodiments be physically combined into more complex blocks without departing from the scope of the proposed method.

[0043] The accompanying drawings are used to help easily understand various technical features and it is understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the proposed method is construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. used herein to describe various elements, these elements are not be limited by these terms. These terms are generally used to distinguish one element from another.

[0044] The various actions, acts, blocks, steps, or the like in the method is performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like are omitted, added, modified, skipped, or the like without departing from the scope of the proposed method.

[0045] The proposed solution outlines a system and method designed to ensure that an IMS(internet protocol multimedia subsystem) network can support IMS DC(IP multimedia subsystem data channel) for an already active IMS session. This method addresses scenarios where there is a requirement to upgrade an existing audio or video call to an IMS DC call. It is suggested that when the originating IMS AS(IMS application server) receives a request from the IVR(interactive voice response), DC Application Server, or the terminating party to initiate IMS DC, it first verifies the originating User Equipment(UE)'s capability for IMS DC by referencing the stored UE context obtained during registration from the S-CSCF(serving call session control function) and checking the subscription status with the HSS(home subscriber server) to confirm the originating UE's authorization for IMS DC usage. Following this verification, and upon receiving approval from the DCSF(data channel signalling function) to proceed with the IMS DC session for the UE, the IMS AS is proposed to send a Re-INVITE containing the IMS DC SDP(session description protocol) offer to the originating UE. Subsequently, the originating UE completes the SDP answer procedure, resulting in a 183 session in progress / 200 OK response, thereby establishing the IMS DC.

[0046] Figure 1 is a block diagram that illustrates a schematic of an IMS AS (102) implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0047] The IMS AS (102) implements and executes a logic for specific services, such as call forwarding, conferencing, messaging, or video streaming. As shown, the IMS AS (102) includes a processor (104), a memory (106), an I / O interface (108), and a first controller (110) communicatively coupled to the processor (104) and the memory (106). Each component is explained in further detail below.

[0048] The processor (104) communicates with the memory (106), the I / O interface (108) and the first controller (110). The processor (104) is configured to execute instructions stored in the memory (106) and to perform various processes. The processor (104) may include one or a plurality of processors, may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

[0049] The memory (106) includes storage locations to be addressable through the processor (104). The memory (106) is not limited to a volatile memory and / or a non-volatile memory. Further, the memory (106) may include a plurality of computer-readable storage media. The memory (106) may include non-volatile storage elements. For example, non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

[0050] The I / O interface (108) transmits the information between the memory (106) and external peripheral devices. The peripheral devices are the input-output devices associated with the IMS AS (102). Further, the first controller (110) communicates with the I / O interface (108) and the memory (106). The first controller (110) may be communicatively coupled to the memory (106) and the processor (104). The first controller (110) is an innovative hardware that is realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0051] In an embodiment, the first controller (110) receives a request from a third party network apparatus to add or remove an IMS DC to an existing IMS session established between a first UE and a second UE. The IMS DC enables the transmission of non-media data (for example, text, files, or custom data) as part of a multimedia session. It is generally used in scenarios requiring real-time communication or data sharing that complements traditional voice, video, or messaging services. The IMS session establishes and manages communication sessions between the first UE and the second UE. The IMS session may also be referred to as a SIP(session initiation protocol)-based multimedia session that enables a range of services such as voice calls, video conferencing, messaging, and the like.

[0052] The received request includes updating or adding the IMS DC to at least one of an established audio call or an established video call of the existing IMS session. Further, the received request may also include adding or removing bootstrap data channels or application data channels in the existing IMS session. The bootstrap data channel is a foundational channel established at the start of the IMS session. It is generally used to set up or negotiate additional communication parameters or to facilitate the initiation of more specialized data channels (for example, application data channels). The application data channel is a specialized data channel used during the active phase of the IMS session to transmit application-specific data. The application data channels are created based on the requirements negotiated during the session setup (often facilitated by a bootstrap data channel).

[0053] In an embodiment, the first controller (110) determines whether the first UE has a capability for the IMS DC. The capability is determined based on a stored UE context and a user subscription information received from a home subscriber server (HSS) indicating whether the first UE is authorized to use the IMS DC. The stored UE context refers to a set of data maintained by network elements to manage and optimize communication with a specific device UE. This context is dynamically created and updated as the UE interacts with the IMS AS (102). For instance, the UE context may include information such as user identification, device state information, session information, security parameters, location information, and the like.

[0054] In an embodiment, the first controller (110) generates a session event control notify request message to be transmitted to a DCSF when the first UE has the capability for the IMS DC and is authorized to use the IMS DC. The session event control notify request message includes the request received from the third party network apparatus. The session event control notify request message is a signaling message used within the IMS AS (102) to communicate events or status updates related to a multimedia session or a user's service. It is generally used in the context of event-based control mechanisms to notify the DCSF about specific events or changes in a session or subscription.

[0055] In an embodiment, the first controller (110) receives a media control request message from the DCSF that includes instructions to add or remove the IMS DC to the existing IMS session established. The media control request message is a signaling message used in IMS to manage or modify media streams during an active multimedia session. It enables dynamic control of media properties such as pausing, resuming, changing codecs, adjusting bandwidth, or modifying session parameters without disrupting the IMS session.

[0056] In an embodiment, the first controller (110) generates a reject request to be transmitted to the third party network apparatus to add or remove the IMS DC to the existing IMS session established, when the first UE does not have the capability for the IMS DC and is not authorized to use the IMS DC. When the first controller (110) generates the reject request, it undertakes the responsibility of processing it in a manner that ensures the integrity and continuity of the existing IMS session. This processing may involve two primary actions: updating the existing IMS session to reflect the current capabilities of the first UE or adding the IMS DC to the session if the conditions allow for it.

[0057] In an embodiment, the first controller (110) generates a re-INVITE request message to be transmitted to the first UE upon receiving the media control request message. The re-INVITE request message contains a session description protocol (SDP) that provides the media information necessary for the IMS DC as required by the third party network apparatus. This re-INVITE request facilitates the updating or addition of the IMS DC to at least one established audio or video call within the existing IMS session.

[0058] Figure 2 is a block diagram that illustrates a schematic of a third party network apparatus (202) implemented to carry out the disclosed subject matter according to an embodiment herein.

[0059] For instance, the third party network apparatus (202) may include, but not limited to an application function (AF), an untrusted AF, a data channel application server (DCAS), and the like. The DCAS facilitates the handling, processing, and management of data channels established during multimedia communication sessions. The data channels are used to transfer non-media data (for example, text, files, metadata, IoT(internet of things) data) in real-time, often complementing audio and video streams.

[0060] As shown, the third party network apparatus (202) includes a second processor (204), a second memory (206), a second I / O interface (208), and a second controller (210) communicatively coupled to the second processor (204) and the second memory (206). The second controller (210) communicates with the second I / O interface (208) and the second memory (206). The second controller (210) may be communicatively coupled to the second memory (206) and the second processor (204). The second controller (210) is an innovative hardware that is realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0061] In an embodiment, the second controller (210) generates a request to be transmitted to the IMS AS (102). The request communicates the necessity to either update the current configuration or to incorporate a new IMS DC into an ongoing IMS session that is taking place between the first and second UEs.

[0062] In an embodiment, the second controller (210) determines whether to add or remove the IMS DC to the existing IMS session based on a local policy or an event notification of the existing IMS Session that the third party network apparatus (202) subscribes to. The local policy or event notification outlines operational guidelines for managing IMS sessions, as well as any relevant event notifications that pertain to the existing IMS session. These notifications are actively monitored by the third party network apparatus (202), ensuring that any changes in the IMS session's status or requirements are promptly addressed.

[0063] In an embodiment, the second controller (210) generates a session management update request message. This message is generated based on the insights gained from the local policy and the event notifications associated with the current IMS session. Once formulated, this message is sent to a Network Exposure Function (NEF), which plays a pivotal role in managing network resources and facilitating communication between different network components. The primary function of the session management update request message is to either add or remove bootstrap data channels or application data channels within the framework of the existing IMS session. By doing so, this ensures that the IMS session remains dynamic and responsive to the needs of the UEs involved, thereby enhancing the overall user experience and optimizing network resource utilization.

[0064] Figure 3 is a block diagram that illustrates a schematic of a DCSF (302) implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0065] The DCSF (302) is responsible for handling the signaling and control of data channels within the IMS AS (102). The DCSF (302) manages the establishment, modification, and termination of data channels, ensuring seamless coordination between the signaling and media components of the IMS session.

[0066] As shown, the DCSF (302) includes a third processor (304), a third memory (306), a third I / O interface (308), and a third controller (310) communicatively coupled to the third processor (304) and the third memory (306). The third controller (310) communicates with the third I / O interface (308) and the third memory (306). The third controller (310) may be communicatively coupled to the third memory (306) and the third processor (304). The third controller (310) is an innovative hardware that is realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0067] In an embodiment, the third controller (310) receives a session event control notify request message from the IMS AS (102). The session event control notify request message indicates that a first UE has a capability for an IMS DC and is authorized to use the IMS DC. This enables the third controller (310) to manage and coordinate the session effectively, ensuring that the first UE can leverage the benefits of IMS DC, such as improved data throughput, enhanced reliability, and seamless service continuity.

[0068] In an embodiment, the third controller (310) generates a media control request message to be transmitted to the IMS AS (102) upon receiving the session event control notify request message. The media control request message contains directives that instruct the IMS AS (102) on how to modify the existing media streams associated with the existing IMS session. The directives within the media control request message may include instructions to incorporate the IMS DC into the ongoing or existing IMS session. This incorporation may involve adding new media capabilities, adjusting the quality of service parameters, or enabling additional features that enhance the user experience during the IMS session.

[0069] Figure 4 is a sequence diagram that illustrates a scenario network initiated IMS DC procedure according to an embodiment as disclosed herein.

[0070] As shown in the sequence diagram, a first UE (402A), a P-CSCF (proxy call session control function, 404), an S-CSCF (406), a HSS (408), the IMS AS (102), the DCSF (302), a NEF (410), the third party network apparatus (202), and a second UE (402B) are in communication with each other.

[0071] At step 1, an IMS audio call is established between the first UE (402A) and the second UE (402B).

[0072] At step 2, the second UE (402B) decides to have an IMS DC session with the first UE (402A).

[0073] At step 3, the second UE (402B) sends a request to the third party network apparatus (202) upon deciding to have the IMS DC session with the first UE (402A).

[0074] In steps 4a-4b (as shown in the sequence diagram), AF session requests (DC session requests) are communication between the IMS AS (102), the DCSF (302), the NEF (410), and the third party network apparatus (202).

[0075] At step 5, the IMS AS (102) transmits an IMS Subscriber data Get Request to the HSS (408). This request is placed for obtaining stored UE context and user subscription information associated with the first UE (402A).

[0076] At step 6, the HSS (408) communicates this information requested to the IMS AS (102) via a IMS Subscriber data Get Response.

[0077] At step 7, the IMS AS (102) decides to send the DC session request to the first UE (402A).

[0078] At step 8, the Subscriber data Get Request (for example, User ID of the first UE (402A)) is communicated to the HSS (408) from the S-CSCF (406).

[0079] At step 9, the IMS AS (102) sends a Nimsas_SessionEventControl_Notify message to the DCSF (302).

[0080] At step 10, the DCSF (302) instructs the IMS AS (102) to set up or remove the data channel(s) by sending a Nimsas_MediaControl request. Depending on the instruction from DCSF (302), the IMS AS (102) may interact with the MF-2 to allocate data channel resources. The procedures depicted in clause AC.7 are reused for interaction with MF.

[0081] At step 11, the IMS AS (102) transmits a re-INVITE request message to be transmitted to the first UE (402A). The IMS AS (102) generates the re-INVITE request(s) in which the SDP offer contains the media information of the data channel required by the third party network apparatus (202) with the other existing media descriptions. The IMS AS (102) sends the re-INVITE request(s) according to the instructions received from DCSF (302).

[0082] The proposed solution addresses the situation where there is a requirement to upgrade an existing audio or video call to an IMS DC call. It is recommended that when the originating IMS AS (102) receives a request from the IVR or the third party network apparatus (202) / AF or the terminating party to initiate IMS DC, it verifies whether the first (UE (402A) / originating UE is capable of IMS DC by referencing the stored UE context obtained during registration from the Serving Call Session Control Function (S-CSCF) (406) and the subscription details from the HSS (408) to confirm the authorization of the first UE (402A) for IMS DC usage. Following this verification, the DCSF (302) assesses the request, and if it permits the IMS DC session for the second UE (402B), the IMS AS (102) will send a re-INVITE message containing the IMS DC SDP offer to the first UE (402A). The first UE (402A) will then complete the SDP answer process with a 183 session in progress / 200 OK response, thereby establishing the IMS DC connection. In Fig. 4, only relevant changes have been highlighted and after this step the further steps are aligned with the 15th step onwards from TS 23.228 AC.7.1-1 fig.

[0083] Figure 5 is a flow diagram that illustrates a method for supporting a network initiated IMS DC by the IMS AS (102) according to an embodiment as disclosed herein. The method includes steps (502-512). Each step is explained in further detail below.

[0084] At step (502), the IMS AS (102) receives a request from the third party network apparatus (202) to add or remove an IMS DC to an existing IMS session established between the first UE (402A) and the second UE (402B). The IMS DC facilitates the transfer of non-media data, such as text, files, or custom information, within a multimedia session. This capability is typically employed in situations that necessitate real-time communication or data exchange, enhancing conventional voice, video, or messaging services. The IMS session is responsible for establishing and overseeing communication sessions between the first UE (402A) and the second UE (402B). Additionally, the IMS session may be described as a SIP-based multimedia session, supporting various services including voice calls, video conferencing, and messaging.

[0085] The received request pertains to the modification or addition of the IMS DC to at least one established audio or video call within the current IMS session. Additionally, the request may involve the inclusion or removal of bootstrap data channels or application data channels in the ongoing IMS session. The bootstrap data channel serves as a fundamental channel initiated at the beginning of the IMS session, primarily utilized for establishing or negotiating further communication parameters and enabling the setup of more specialized data channels, such as application data channels. In contrast, the application data channel is a dedicated channel employed during the active phase of the IMS session for the transmission of application-specific data. These application data channels are established based on the requirements agreed upon during the session setup, typically facilitated by the bootstrap data channel.

[0086] At step (504), the IMS AS (102) determines whether the first UE (402A) has a capability for the IMS DC. The capability is assessed using a stored UE context along with user subscription details obtained from the HSS (408), which indicates if the first UE (402A) has the authorization to access the IMS DC. The stored UE context consists of a collection of data that network components utilize to manage and enhance communication with the second UE (402B). This context is generated and modified in real-time as the first UE (402A) engages with the IMS AS (102). For example, the UE context may include data such as user identification, device status, session details, security settings, location data, and the like.

[0087] At step (506), the IMS AS (102) generates a session event control notify request message to be transmitted to the DCSF (302) when the first UE (402A) has the capability for the IMS DC and is authorized to use the IMS DC. The session event control notify request message encompasses the request obtained from the third party network apparatus (202). This signaling message is utilized within the IMS AS (102) to convey events or status updates pertinent to a multimedia session or a user's service. Typically, it is employed in event-driven control mechanisms to inform the DCSF (302) of particular events or modifications in a session or subscription.

[0088] At step (508), the IMS AS (102) receives a media control request message from the DCSF (302) that includes instructions to add or remove the IMS DC to the existing IMS session established. The media control request message serves as a signaling tool within IMS, facilitating the management or alteration of media streams during an ongoing multimedia session. This message allows for the dynamic adjustment of media attributes, including pausing, resuming, changing codecs, modifying bandwidth, or altering session parameters, all while maintaining the integrity of the IMS session.

[0089] At step (510), the IMS AS (102) generates a reject request to be transmitted to the third party network apparatus (202) to add or remove the IMS DC to the existing IMS session established, when the first UE (402A) does not have the capability for the IMS DC and is not authorized to use the IMS DC. Upon generating the reject request, the IMS AS (102) is tasked with handling it in a way that maintains the integrity and continuity of the ongoing IMS session. This handling may include two main actions: modifying the current IMS session to align with the capabilities of the first UE (402A) or incorporating the IMS DC into the session, provided that the circumstances permit.

[0090] At step (512), the IMS AS (102) generates a re-INVITE request message to be transmitted to the first UE (402A) upon receiving the media control request message. The re-INVITE request message includes a session description protocol (SDP) that supplies the media information needed for the IMS DC, as mandated by the third party network apparatus (202). This re-INVITE request enables the updating or incorporation of the IMS DC into at least one ongoing audio or video call within the current IMS session.

[0091] Figure 6 is a flow diagram that illustrates a method for supporting a network initiated IMS DC by the third party network apparatus (202) according to an embodiment as disclosed herein. The method includes steps (602-606). Each step is explained in further detail below.

[0092] At step (602), the third party network apparatus (202) generates a request to be transmitted to the IMS AS (102). The request indicates the need to either modify the existing configuration or to integrate a new IMS DC into the ongoing IMS session occurring between the first UE (402A) and the second UE (402B).

[0093] At step (604), the third party network apparatus (202) determines whether to add or remove the IMS DC to the existing IMS session based on a local policy or an event notification of the existing IMS Session that the third party network apparatus (202) subscribes to. The local policy or event notification provides operational directives for overseeing IMS sessions, along with pertinent event notifications related to the current IMS session. The third party network apparatus (202) actively monitors these notifications to ensure that any alterations in the status or requirements of the IMS session are addressed in a timely manner.

[0094] At step (606), the third party network apparatus (202) generates a session management update request message. This message is created using insights derived from local policy and event notifications related to the ongoing IMS session. After its formulation, the message is dispatched to the NEF (410), which is crucial for overseeing network resources and enabling communication among various network elements. The main purpose of the session management update request message is to either incorporate or eliminate bootstrap data channels or application data channels within the context of the current IMS session. This process ensures that the IMS session is adaptable and responsive to the requirements of the UEs involved, ultimately improving the user experience and optimizing the use of network resources.

[0095] Figure 7 is a flow diagram that illustrates a method for supporting a network initiated IMS DC by the DCSF (302) according to an embodiment as disclosed herein. The method includes steps (702-704). Each step is explained in detail below.

[0096] At step (702), the DCSF (302) receives a session event control notify request message from the IMS AS (102). The session event control notify request message signifies that the first UE (402A) possesses the capability for an IMS DC and is permitted to utilize it. This allows the DCSF (302) to efficiently oversee and coordinate the session, ensuring that the first UE (402A) can take advantage of the benefits offered by IMS DC, including increased data throughput, enhanced reliability, and uninterrupted service continuity.

[0097] At step (704), the DCSF (302) generates a media control request message to be transmitted to the IMS AS (102) upon receiving the session event control notify request message. The media control request message includes instructions that guide the IMS AS (102) on how to alter the current media streams linked to the active IMS session. These instructions may specify the integration of the IMS DC into the ongoing IMS session. This integration could entail introducing new media functionalities, modifying quality of service (QoS) settings, or activating extra features that improve the user experience throughout the IMS session.

[0098] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

1.A method performed by an IP (internet protocol) multimedia subsystem (IMS) application server (AS) in a communication system, the method comprising:receiving, from a data channel application server (DC AS) via a network exposure function (NEF), a session update request message requiring to add a data channel (DC) on an existing IMS session established between a first user equipment (UE) and a second UE;determining whether the first UE has a capability for an IMS DC and the first UE is authorized to access the IMS DC;transmitting, to a data channel signalling function (DCSF), an event notification on the existing IMS session, in case that the first UE has the capability and the first UE is authorized to access the IMS DC;receiving, from the DCSF, a media control request message including an instruction of adding the DC on the existing IMS session, in response to the event notification; andtransmitting, to the first UE, a re-INVITE message for adding the DC on the existing IMS session, based on the instruction.2.The method of claim 1, further comprising:receiving, from a home subscriber server (HSS), a subscription data for the IMS DC,wherein the subscription data is used for authorizing the first UE to access the IMS DC.3.The method of claim 1,wherein the event notification includes information on a media operation indicating a modification of a media in the existing IMS session,wherein the information is included in the session update request message, andwherein the instruction controls each media flow in the existing IMS session.4.The method of claim 1,wherein the re-INVITE message includes a session description protocol (SDP) providing media information on the DC, required by the DC AS, with a media description of the existing IMS session.5.A method performed by a first user equipment (UE) in a communication system, the method comprising:identifying an existing IP (internet protocol) multimedia subsystem (IMS) session established between the first UE and a second UE;receiving, from an IMS application server (AS), a re-INVITE message for adding the DC on the existing IMS session, in case that the first UE has a capability for an IMS DC and the first UE is authorized to access the IMS DC; andmodifying the existing IMS session based on the re-INVITE message.6.The method of claim 5,wherein the re-INVITE message includes a session description protocol (SDP) providing media information on the DC, required by the DC AS, with a media description of the existing IMS session.7.A method performed by a data channel signalling function (DCSF) in a communication system, the method comprising:receiving, from an IP (internet protocol) multimedia subsystem (IMS) application server (AS), an event notification on an existing IMS session established between a first user equipment (UE) and a second UE, in case that the first UE has a capability for an IMS DC and the first UE is authorized to access the IMS DC; andtransmitting, to the IMS AS, a media control request message including an instruction of adding the DC on the existing IMS session, in response to the event notification,wherein a re-INVITE message for adding the DC on the existing IMS session is transmitted to the first UE, based on the instruction.8.The method of claim 7,wherein the event notification includes information on a media operation indicating a modification of a media in the existing IMS session,wherein the information is included in the session update request message,wherein the instruction controls each media flow in the existing IMS session, andwherein the re-INVITE message includes session description protocol (SDP) providing media information on the DC, required by the DC AS, with a media description of the existing IMS session.9.An IP (internet protocol) multimedia subsystem (IMS) application server (AS) in a communication system, the IMS AS comprising:a processor; anda controller coupled with the processor and configured to:receive, from a data channel application server (DC AS) via a network exposure function (NEF), a session update request message requiring to add a data channel (DC) on an existing IMS session established between a first user equipment (UE) and a second UE,determine whether the first UE has a capability for an IMS DC and the first UE is authorized to access the IMS DC,transmit, to a data channel signalling function (DCSF), an event notification on the existing IMS session, in case that the first UE has the capability and the first UE is authorized to access the IMS DC,receive, from the DCSF, a media control request message including an instruction of adding the DC on the existing IMS session, in response to the event notification, andtransmit, to the first UE, a re-INVITE message for adding the DC on the existing IMS session based on the instruction.10.The IMS AS in claim 9,wherein the controller is further configured to receive, from a home subscriber server (HSS), a subscription data for the IMS DC, andwherein the subscription data is used for authorizing the first UE to access the IMS DC.11.The IMS AS in claim 9,wherein the event notification includes information on a media operation indicating a modification of a media in the existing IMS session,wherein the information is included in the session update request message,wherein the instruction controls each media flow in the existing IMS session, andwherein the re-INVITE message includes a session description protocol (SDP) providing media information on the DC required by the DC AS, with a media description of the existing IMS session.12.A first user equipment (UE) in a communication system, the first UE comprising:processor; andcontroller coupled with the processor and configured to:identify an existing IP (internet protocol) multimedia subsystem (IMS) session established between the first UE and a second UE,receive, from an IMS application server (AS), a re-INVITE message for adding the DC on the existing IMS session, in case that the first UE has a capability for an IMS DC and the first UE is authorized to access the IMS DC, andmodify the existing IMS session based on the re-INVITE message.13.The first UE of claim 12,wherein the re-INVITE message includes a session description protocol (SDP) providing media information on the DC, required by the DC AS, with a media description of the existing IMS session14.A data channel signalling function (DCSF) in a communication system, the DCSF comprising:a processor; anda controller coupled with the processor and configured to:receive, from an IP (internet protocol) multimedia subsystem (IMS) application server (AS), an event notification on an existing IMS session established between a first user equipment (UE) and a second UE, in case that the first UE has a capability for an IMS DC and the first UE is authorized to access the IMS DC, andtransmit, to the IMS AS, a media control request message including an instruction of adding the DC on the existing IMS session, in response to the event notification,wherein a re-INVITE message for adding the DC on the existing IMS session is transmitted to the first UE, based on the instruction.15.The DCSF of claim 14,wherein the event notification includes information on a media operation indicating modification of a media in the existing IMS session,wherein the information is included in the session update request message,wherein the instruction controls each media flow in the existing IMS session, andwherein the re-INVITE message includes a session description protocol (SDP) providing media information on the DC, required by the DC AS, with a media description of the existing IMS session.

Images