Method and apparatus for providing IMS communication service

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. The method for providing an IP multimedia subsystem (IMS) data channel (DC) service by a network exposure function (NEF) may comprise the steps of: receiving, from a data channel (DC) application server (AS), a first request for adding or removing a DC to or from an existing IMS session; querying a home subscriber server (HSS) to identify an IMS AS for a user equipment (UE); and transmitting, to the identified IMS AS, a second request for adding or removing a DC to or from the existing IMS session.

Description

Method and device for providing IMS communication services The present disclosure relates to a method and device for providing a service in IMS (IP Multimedia Subsystem) communication. 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band, such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (㎜Wave), such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low delay time that is reduced by one-tenth. In the early stages of 5G mobile communication technology, the goal was to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). The technologies included beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2 Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing. Currently, discussions are underway on improving and enhancing the initial 5G mobile communication technology in consideration of the services that the 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning. In addition, standardization of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) to provide nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step RACH for NR to simplify random access procedures is also in progress, and standardization of system architecture / services for 5G baseline architecture (e.g. Service based Architecture, Service based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal is also in progress. When such 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, which will require enhanced functions and performance of 5G mobile communication systems and integrated operation of connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, AI service support, metaverse service support, drone communications, etc. using extended reality (XR), artificial intelligence (AI), and machine learning (ML) to efficiently support augmented reality (AR), virtual reality (VR), and mixed reality (MR). In addition, the development of these 5G mobile communication systems will require new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, and AI (Artificial Intelligence) from the design stage and AI-based communication technology that implements end-to-end AI support functions to realize system optimization, and ultra-high-performance communication and computing resources to provide services with a level of complexity that goes beyond the limits of terminal computing capabilities. It could serve as a basis for the development of next-generation distributed computing technologies that utilize this. In order to meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems, efforts are being made to develop improved 5G communication systems or pre-5G communication systems. For this reason, 5G communication systems or pre-5G communication systems are also called Beyond 4G Network communication systems or Post LTE systems. The 5G communication system specified by 3GPP is called New Radio (NR) system. To achieve high data rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., 60 gigahertz (GHz) bands). To mitigate radio path loss and increase the transmission range of radio waves in ultra-high frequency bands, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, and large scale antenna technologies have been discussed and applied to NR systems in 5G communication systems. In addition, to improve the network of the system, technologies such as evolved small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device to device communication (D2D), wireless backhaul, moving networks, cooperative communications, CoMP (Coordinated Multi-Points), and interference cancellation are being developed in 5G communication systems. In addition, advanced coding modulation (ACM) methods such as Hybrid FSK and QAM Modulation (FQAM) and Sliding Window Superposition Coding (SWSC), as well as advanced access technologies such as Filter Bank Multi Carrier (FBMC), Non-Orthogonal Multiple Access (NOMA), and Sparse Code Multiple Access (SCMA) are being developed in 5G systems. Meanwhile, the Internet is evolving from a human-centered network where humans create and consume information to an Internet of Things (IoT) network where information is exchanged and processed between distributed components such as objects. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connection to cloud servers, is also emerging. In order to implement IoT, technological elements such as sensing technology, wireless communication and network infrastructure, service interface technology, and security technology are required, and recently, technologies such as sensor networks for connection between objects, machine-to-machine (M2M), and machine type communication (MTC) are being studied. In the IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated from connected objects to create new values for human life. IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services through convergence and combination between existing IT (Information Technology) technologies and various industries. Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, 5G communication such as sensor networks, machine-to-machine (M2M), and machine-type communication (MTC) are being implemented by techniques such as beam forming, MIMO, and array antennas. The application of cloud radio access networks (cloud RAN) as a big data processing technology described above can also be said to be an example of the convergence of 5G and IoT technologies. The present disclosure relates to providing a process for providing an IMS data channel (DC) service and a device for implementing the same. According to one embodiment of the present disclosure, a method for providing an IP Multimedia Subsystem (IMS) data channel (DC) service by a network exposure function (NEF) is provided. The method may include the steps of: receiving a first request from a data channel (DC) application server (AS) to add or remove a DC to an existing IMS session; querying a home subscriber server (HSS) to identify an IMS AS for a user equipment (UE); and transmitting a second request to the identified IMS AS to add or remove a DC to the existing IMS session. The step of querying the HSS may include the step of transmitting a message including a private identity of the UE to the HSS. The above DC may be a bootstrap DC. The method may further comprise the step of receiving a response to the second request to add or remove a DC to the IMS session from the identified IMS AS. If the above response indicates a failure, the response may include information indicating the cause of the failure. The method may further include the step of transmitting the received response to the DC AS. According to one embodiment of the present disclosure, a device for a network exposure function (NEF) for providing an IMS (IP Multimedia Subsystem) data channel (DC) service may be provided. The device may include a transceiver; and at least one processor connected to the transceiver. The at least one processor may be configured to receive a first request from a data channel (DC) application server (AS) to add or remove a DC to an existing IMS session, query a home subscriber server (HSS) to identify an IMS AS for a user equipment (UE), and transmit a second request to the identified IMS AS to add or remove a DC to the existing IMS session. According to one embodiment of the present disclosure, a method for providing an IMS data channel (DC) service by an IMS (IP Multimedia Subsystem) application server (AS) is provided. The method may include the steps of: receiving a first request message for establishing a DC session with a first UE from a second user equipment (UE), wherein an IMS audio call is established between the first UE and the second UE; obtaining subscriber information for the first UE from a unified data management (UDM) or a home subscriber server (HSS); determining whether to transmit a second request for establishing the DC session to the first UE based on the subscriber information for the first UE and the request for establishing the DC session; and transmitting the second request for establishing the DC session to a serving-call session control function (S-CSCF) for transmission to the first UE based on the determination to transmit the second request for establishing the DC session. According to one embodiment of the present disclosure, a method for providing an IMS (IP Multimedia Subsystem) data channel (DC) service by a network exposure function (NEF) is provided. The method may include: receiving an event exposure subscription message for a first UE from a second user equipment (UE); transmitting the event exposure subscription message for the first UE to a network entity, wherein the network entity is an IMS application server (AS) or a serving-call session control function (S-CSCF); receiving, in response to the event exposure subscription message for the first UE, an event exposure notification message from the network entity, the event exposure notification message including information on whether the first UE supports an IMS DC service; and transmitting the event exposure notification message including information on whether the first UE supports the IMS DC service to the second UE. According to one embodiment of the present disclosure, a device for an IMS application server (AS) for providing an IMS (IP Multimedia Subsystem) data channel (DC) service is provided. The device may include a transceiver; and at least one processor connected to the transceiver. The at least one processor may be configured to receive a first request message for establishing a DC session with a first UE from a second user equipment (UE), wherein an IMS audio call is established between the first UE and the second UE, acquire subscriber information for the first UE from a unified data management (UDM) or a home subscriber server (HSS), determine whether to transmit a second request for establishing the DC session to the first UE based on the subscriber information for the first UE and the request for establishing the DC session, and determine to transmit the second request for establishing the DC session based on the determination to transmit the second request for establishing the DC session, transmit the second request for establishing the DC session to a serving-call session control function (S-CSCF) for transmission to the first UE. Figure 1 illustrates a 5G system architecture related to an embodiment of the present disclosure. Figures 2a and 2b illustrate an IMS network structure according to one embodiment of the present disclosure. FIGS. 3a, 3b and 3c illustrate a method for providing an IMS DC service in a communication system according to one embodiment of the present disclosure. FIG. 4a and FIG. 4b illustrate a method for providing an IMS DC service in a communication system according to one embodiment of the present disclosure. FIG. 5a and FIG. 5b illustrate a method for providing an IMS DC service in a communication system according to one embodiment of the present disclosure. FIGS. 6a and 6b illustrate a method for providing an IMS DC service in a communication system according to an embodiment of the present disclosure. FIG. 7 illustrates a block diagram of a device according to one embodiment of the present disclosure. The operating principle of the present disclosure is described in detail with reference to the attached drawings below. In describing the embodiments, descriptions of technical contents that are well known in the technical field to which the present disclosure belongs and are not directly related to the present disclosure are omitted. This is to convey the gist of the present disclosure more clearly without obscuring it by omitting unnecessary descriptions. For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically illustrated. In addition, the size of each component does not entirely reflect the actual size. The same or corresponding components in each drawing are given the same reference numbers. The advantages and features of the present disclosure, and the methods for achieving them, will become apparent by referring to the embodiments described in detail below together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in various different forms, and the embodiments are provided only to make the present disclosure complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification. At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be loaded onto a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement the function in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured article including an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions may be installed on a computer or other programmable data processing apparatus, a series of operational steps may be performed on the computer or other programmable data processing apparatus to produce a computer-executable process, so that the instructions executing the computer or other programmable data processing apparatus may also provide steps for executing the functions described in the flowchart block(s). Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a particular logical function(s). It should also be noted that in some alternative implementation examples, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may in fact be performed substantially concurrently, or the blocks may sometimes be performed in reverse order, depending on the functionality they perform. Here, the term '~ part' used in this embodiment means a software or hardware component such as an FPGA or ASIC, and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be in an addressable storage medium and may be configured to reproduce one or more processors. Thus, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided in the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. In addition, the components and '~ parts' may be implemented to reproduce one or more CPUs in a device or a secure multimedia card. Additionally, in the embodiment, '~bu' may include one or more processors. In the following description, terms used to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc. are examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used. For convenience of explanation below, this disclosure uses terms and names defined in the 3GPP LTE (3rd Generation Partnership Project Long Term Evolution) standard and the 3GPP 5G standard. However, this disclosure is not limited by the above terms and names, and can be equally applied to systems conforming to other standards. Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the attached drawings. At this time, it should be noted that in the attached drawings, the same components are represented by the same symbols as much as possible. In addition, it should be noted that the drawings of the present disclosure attached below are provided to help understanding of the present disclosure, and the present disclosure is not limited to the forms or arrangements illustrated in the drawings of the present disclosure. Figure 1 illustrates a 5G system architecture related to an embodiment of the present disclosure. Referring to FIG. 1, the 5G system architecture may include various components (i.e., network functions (NFs)). FIG. 1 illustrates some of them, including an authentication server function (AUSF) device (110), an access and mobility management function (AMF) device (103), a session management function (SMF) device (104), a policy control function (PCF) device (107), an application function (AF) device (108), a unified data management (UDM) device (106), a data network (DN) (112), a user plane function (UPF) device (105), a (radio) access network ((R)AN) (102), and a terminal, i.e., a user equipment (UE) (101). In addition, in FIG. 1, a Network Slice Selection Function (NSSF) device (109) and a Network Slice Specific Authentication and Authorization Function (NSSAAF) device (111) are exemplarily illustrated. Each of the devices illustrated in Fig. 1 may be implemented as a single server or device, or may be implemented as a network slice instance. When implemented as a network slice instance, it may be implemented as two or more identical or different network slice instances within a single server or device, or one network slice instance may be implemented on two or more servers or devices. Each NF can support the following functions: AUSF (110) can process and store data for authentication of UE. AMF (103) can provide functions for access and mobility management per UE, and one UE can be connected to one AMF by default. Specifically, the AMF (103) provides signaling between CN (core network) nodes for mobility between 3GPP access networks, termination of a radio access network (RAN) CP interface (i.e., N2 interface), termination of NAS signaling (N1), NAS signaling security (NAS ciphering and integrity protection), AS security control, registration management (registration area management), connection management, idle mode UE reachability (including control and performance of paging retransmission), mobility management control (subscription and policy), intra-system mobility and inter-system mobility support, support for network slicing, SMF selection, lawful intercept (for AMF events and interfaces to the LI system), provision of forwarding of session management (SM) messages between UE and SMF, transparent proxy for routing SM messages, access authentication, and roaming authorization check. It may support functions such as access authorization, provision of SMS messages between the UE and the Short Message Service Function (SMSF), security anchor function (SAF), and / or security context management (SCM). Some or all of these functions of the AMF (103) may be supported within a single AMF instance operating as one AMF. DN (112) may mean, for example, an operator service, Internet access, or a third party service. DN (112) may transmit a downlink protocol data unit (PDU) to UPF (105) or receive a PDU transmitted from UE (101) through UPF (105). PCF (107) can receive information about packet flow from an application server and provide a function for determining policies such as mobility management and session management. Specifically, PCF (107) can support functions such as supporting a unified policy framework for controlling network operations, providing policy rules so that control plane function(s) (e.g., AMF, SMF, etc.) can enforce the policy rules, and implementing a front end for accessing related subscription information for policy determination in a user data repository (UDR). The SMF (104) provides session management functions, and when a UE has multiple sessions, each session can be managed by a different SMF. Specifically, the SMF (104) can support functions such as session management (e.g., session establishment, modification, and termination, including tunnel maintenance between the UPF and the AN node), UE IP address allocation and management (optionally including authentication), selection and control of UP functions, traffic steering setup for routing traffic from the UPF to an appropriate destination, termination of the interface toward policy control functions, enforcement of the control portion of policies and QoS (quality of service), lawful intercept (for SM events and interfaces to the LI system), termination of the SM portion of NAS messages, downlink data notification, initiator of AN specific SM information (delivered to the AN through N2 via AMF), determination of the SSC mode of the session, and roaming functions. As described above, some or all of the functions of SMF (104) may be supported within a single SMF instance operating as a single SMF. UDM (106) can store user subscription data, policy data, etc. UDM (106) can include two parts, namely, an application front end (FE) (not shown) and a user data repository (UDR) (not shown). The FE may include a UDM FE responsible for location management, subscription management, and credential processing, and a PCF-FE responsible for policy control. The UDR may store data required for functions provided by the UDM-FE and policy profiles required by the PCF. Data stored in the UDR may include user subscription data and policy data including subscription identifiers, security credentials, access and mobility related subscription data, and session related subscription data. The UDM-FE may access subscription information stored in the UDR and support functions such as authentication credential processing, user identification handling, access authentication, registration / mobility management, subscription management, and SMS management. UPF (105) can forward a downlink PDU received from DN (112) to UE (101) via (R)AN (102), and can forward an uplink PDU received from UE (101) via (R)AN (102) to DN (112). Specifically, the UPF (105) may support an anchor point for intra / inter RAT mobility, an external PDU session point for interconnection to a Data Network, a user plane portion of packet routing and forwarding, packet inspection and policy rule enforcement, an uplink classifier to support lawful intercept, traffic usage reporting, and routing of traffic flows to the Data Network, a branching point to support multi-homed PDU sessions, QoS handling for the user plane (e.g., packet filtering, gating, uplink / downlink rate enforcement), uplink traffic validation (service data flow (SDF) to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering, and downlink data notification triggering functions. Some or all of these functions of the UPF (105) may be supported within a single UPF instance operating as a single UPF. The AF (108) can interact with the 3GPP core network to provide services (e.g., supporting functions such as application influence on traffic routing, access to network capability exposure, and interaction with the policy framework for policy control). (R)AN(102) may collectively refer to a new radio access network that supports both evolved E-UTRA, an evolved version of 4G radio access technology, and new radio (NR) technology (e.g., gNB). The gNB provides functions for radio resource management (i.e., radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to the UE in uplink / downlink (i.e., scheduling), IP (internet protocol) header compression, encryption and integrity protection of user data streams, selection of the AMF (103) upon attachment of the UE (101) if routing to the AMF (103) is not determined from information provided to the UE (101), routing of user plane data to the UPF (105)(s), routing of control plane information to the AMF (103), connection setup and teardown, scheduling and transmission of paging messages (originating from the AMF), scheduling and transmission of system broadcast information (originating from the AMF or operating and maintenance (O&M)), measurement and measurement reporting setup for mobility and scheduling, It can support functions such as transport level packet marking in uplink, session management, support for network slicing, QoS flow management and mapping to data radio bearer, support for UE in inactive mode, distribution of NAS messages, NAS node selection, radio access network sharing, dual connectivity, and tight interworking between NR and E-UTRA. UE (101) may mean a user equipment. The user equipment may be referred to by terms such as terminal, mobile equipment (ME), mobile station (MS), etc. In addition, the user equipment may be a portable device such as a laptop, a mobile phone, a personal digital assistant (PDA), a smart phone, a multimedia device, etc., or may be a non-portable device such as a personal computer (PC) or a vehicle-mounted device. Hereinafter, the user equipment (UE) or terminal will be referred to as such. In Fig. 1, for clarity of explanation, a network exposure function (NEF) device and an NF repository function (NRF) device are not illustrated, but all NFs illustrated in Figs. 2a to 5 described below can interact with the NEF and NRF as needed. Let's take a look at NRF. NRF (not shown in Fig. 1) can support service discovery function. When receiving a second NF discovery request from a first NF instance, it can provide information on the second NF instance discovered after performing the second NF discovery operation to the first NF instance. In addition, it can maintain available NF instances and the services they support. Meanwhile, for convenience of explanation, FIG. 1 illustrates a reference model for a case where a UE accesses one DN using one PDU session, but the present disclosure is not limited thereto. A UE (101) can access two (i.e., local and central) data networks simultaneously using multiple PDU sessions. At this time, two SMFs can be selected for different PDU sessions. However, each SMF can have the ability to control both the local UPF and the central UPF within the PDU session. Additionally, the UE (101) may simultaneously access two (i.e., local and central) data networks provided within a single PDU session. The control plane components of 5GC can be considered as virtualized network functions (VNFs), and communication between the VNFs can be considered as a RESTful-based API exchange, where one VNF provides a service to other VNFs. The API-based communication interface between the VNFs is called a Service Based Interface (SBI). In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. The following is an example of a reference point included in the 5G system architecture represented in Fig. 1. - N1: Reference point between UE and AMF - N2: Reference point between (R)AN and AMF - N3: Reference point between (R)AN and UPF - N4: Reference point between SMF and UPF - N5: Reference point between PCF and AF - N6: Reference point between UPF and data network - N7: Reference point between SMF and PCF - N8: Reference point between UDM and AMF - N9: Reference point between two core UPFs - N10: Reference point between UDM and SMF - N11: Reference points between AMF and SMF - N12: Reference point between AMF and AUSF - N13: Reference point between UDM and authentication server function (AUSF) - N14: Reference point between two AMFs - N15: Reference point between PCF and AMF for non-roaming scenarios, reference point between PCF and AMF in visited network for roaming scenarios. In the following description, the term terminal may refer to UE (101), and the terms UE and terminal may be used interchangeably. In this case, unless the term terminal is specifically defined additionally, it should be understood as UE (101). A terminal connects to a data network (e.g., a network providing Internet service) through a 5G system to establish a session, and each data network can be distinguished using an identifier called a Data Network Name (DNN). The DNN can be used to determine NFs, inter-NF interfaces, operator policies, etc. related to a user plane when the terminal connects a session with a network system. The DNN can be used, for example, to select SMF and UPF(s) for a PDU session, and can be used to select interface(s) (e.g., N6 interface)(s) between a data network and a UPF for a PDU session. In addition, the DNN can be used to determine a mobile communication operator's policy to be applied to a PDU session. FIG. 2a and FIG. 2b illustrate an IMS network structure according to one embodiment of the present disclosure. Refer to the contents of Figure 1, and omit duplicate explanations. Referring to FIGS. 2A and 2B, a UE (User Equipment) (101) can communicate with other UEs (not shown) located in a remote IMS network (260) and IM CN subsystem components through an IM CN (IP Multimedia Core Network) subsystem. The IM CN subsystem can include a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230), an IMS HSS (240), an IMS AGW (250), and / or an MRF (270), and the components can perform the following functions. - P-CSCF (Proxy Call Session Control Function)(210): P-CSCF can perform the function of the first contact point for UE to access IMS. - I / S-CSCF (Interrogating / Serving CSCF)(220): I-CSCF can perform the function of a contact point for subscribers of a network operator or roaming users currently located in the service area of said network operator. S-CSCF can handle the actual user session state of the network. - IMS AS (Application Server)(230): IMS AS can provide and execute IM (Internet Multimedia) value added services. In addition, IMS AS can affect SIP (Session Initiation Protocol) sessions by acting on behalf of services supported in the operator network. - IMS HSS (Home Subscriber Server)(240): IMS HSS can act as a database that stores information about users. - IMS-AGW (Access Gateway)(250): IMS-AGW is located in the media transmission path and can manage network addresses associated with inbound and outbound media streams. - MRF (Media Resource Function)(270): MRF can perform various processing tasks related to media streams. MRF can be divided into MRFC (Multimedia Resource Function Controller) responsible for control and MRFP (Multimedia Resource Function Processor) responsible for media processing. Referring to FIGS. 2a and 2b, the interfaces between the components can be expressed by the following reference points. - Gm: Reference point Gm can support communication between UE and IM CN subsystem. For example, UE can request network registration and session control through the Gm reference point. SIP, which will be described later, can be used for the Gm reference point. - Mw: Reference point Mw can support the exchange and transmission of signaling messages between CSCFs. - ISC: Reference point ISC can support the exchange of information required for services provided by the service platform (e.g. IMS AS) between the S-CSCF and the service platform. - Sh: Reference point Sh can support the exchange of information required for the service provided by the service platform (e.g. IMS AS) between the HSS and the service platform. - Cx: Reference point Cx can support information transfer between HSS and CSCF. - Mr' / Cr: Reference point Mr' can support interaction for session control between IMS AS and MRFC, and reference point Cr can support interaction for media control between IMS AS and MRFC. - Iq: Reference point Iq can support the exchange of information required for allocation and release of transport addresses between P-CSCF and IMS AGW. - Mb: Reference point Mb can support IMS media transfer between IMS components. Referring to FIGS. 2a and 2b, a P-CSCF (210) supporting a Service Based Interface (SBI) can communicate with a Policy Control Function (PCF) (107), which can be represented by reference point N5. The PCF (107) can support policy setting and distribution for managing network operations, and the P-CSCF (210) supporting the SBI can be considered as an application function (AF: Application Function) that uses a service that the PCF (107) provides to other VNFs. An HSS (240) supporting SBI can communicate with an I / S-CSCF (220) supporting SBI through reference point N70, and can communicate with an IMS AS (230) supporting SBI through reference point N71. Similarly, the I / S-CSCF (220) supporting SBI and the IMS AS (230) supporting SBI can be regarded as AFs that use services provided by the HSS (240) supporting SBI, and the functions provided by the reference points N70 and N71 can be equivalent to the functions provided by reference point Cx and reference point Sh, respectively. The above SIP is an application layer signaling protocol that specifies the procedures for intelligent terminals that want to communicate on the Internet to identify each other, find their locations, and create or delete / change multimedia communication sessions between them. SIP is a request / response structure that controls the creation, modification, and termination of multimedia service sessions such as Internet-based conferences, telephones, voice mail, event notifications, and instant messaging. It can be used for both TCP and UDP, and by using a SIP URL similar to an email address to distinguish each user, services are provided regardless of IP addresses. SIP is text-based and was developed using many parts of HTTP and SMTP as is, so it is easy to implement, and it has the flexibility and expandability to create various services by combining it with many other protocols used on the Internet. SIP is a simpler protocol corresponding to ITU-T's H.323. It was proposed as RFC 2543 by the IETF MMUSIC (Multiparty Multimedia Session Control) working group in 1999. Afterwards, the separately separated IETF SIP working group conducted revisions and the RFC3261 standard was established in July 2002. In order to provide a service (e.g., a real-time interaction service) in a communication system according to various embodiments of the present disclosure, there must be an agreement on a media session composing the service between user UEs participating in the service. In order to provide a service (e.g., a real-time interaction service), the communication system according to various embodiments of the present disclosure can perform an agreement on the media session through SDP (Session Description Protocol) negotiation. The above SDP can be included in a SIP message. The above SDP is an ASCII sentence-based protocol for describing multimedia sessions and related schedule information. SDP conveys information about media streams of a multimedia session so that the session can be joined, and a multimedia session is defined as a set of media streams for a duration, and the time during which the session is in progress need not be continuous. A multicast-based session on the Internet basically has two purposes: a means of notifying the existence and time of the session and a means of conveying session joining information, and in a unicast environment, the latter is the purpose. The SDP information content can include the name and purpose of the session, session progress time, session configuration media, media reception information, etc. Below, various embodiments of the present disclosure are described assuming that the service provided in the communication system is a real-time interaction service, but are not limited thereto. In a communication system according to various embodiments of the present disclosure, a web application for providing a service (e.g., a real-time interaction service) may be provided from a Data Channel Application Server (DCAS). The Data Channel Application Server may be located in an IMS operator network or a third-party network. In the present disclosure, a web application provided by the Data Channel Application Server may be referred to as a Data Channel Application (DCA). A terminal participating in a service (e.g., a real-time interaction service) provided by the Data Channel Application may exchange data required by the service directly or through an intermediate node with another terminal participating in the same service using a Data Channel (DC), and may communicate with the Data Channel Application Server using a Bootstrap Data Channel (BDC). A communication system may include a UE (101) and an IM CN subsystem. The UE (101) may communicate with other UEs located in a remote IMS network (260) and components of the IM CN subsystem via the IM CN subsystem. The IM CN subsystem may include a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230) an IMS HSS (240), an IMS AGW (250), a data channel signaling function (310), a media function (321), a NEF (330), a data channel application server (340) and / or a data channel application repository (350). The above data channel signaling function (310) can perform the following functions: - Management and control of data channels, including bootstrap data channels. - Data channel management and event creation / reception through communication with IMS AS - Management and distribution control of data channel applications - Communication with 5G network functions (NF) for providing data channel application services - Proxy role for resource distribution of data channel application server (340) The above data application storage (350) can store and manage data channel applications and can be located inside or outside the data channel server (340). The above media function (321) and MRF (270) can perform the following functions: - Management and control of media resources to be transmitted over data channels, including bootstrap data channels. - Acts as a proxy for data exchange between the endpoint of the data channel connected to the terminal and other endpoints The above media function (321) and MRF (270) provide equivalent functions with different interfaces, and the operator may include only one of the media function (321) and the MRF (270) in the data channel server (340) or may include both, taking into consideration compatibility with other network equipment and user terminals. FIGS. 3a, 3b and 3c illustrate a method for providing an IMS DC service in a communication system according to one embodiment of the present disclosure. Refer to the contents of Figures 1 and 2, and duplicate explanations are omitted. 301. An IMS audio call can be established between UE#1 and UE#2. 302. UE#2 may decide to additionally set up an IMS DC call to the ongoing IMS audio call with UE#1. For example, while a customer is receiving consultation by making a voice call to customer center UE#2 through UE#1, customer center UE#2 may additionally decide to add an IMS DC call so that the customer can receive consultation through a visual data menu on the terminal screen. 303. UE#2 may request DC AS / AF (data channel application server or data channel application function) to establish a DC session. The request may include an indication requesting to establish a Bootstrap DC session (Bootstrap DC request indication), User ID of UE#1 and / or UE#2 (e.g., user's external ID, user's Public User Identities, Private User Identities, IMPU, IMPI, etc.), Group information (e.g., external group ID, etc.), Service ID (e.g., IMS Communication Service Identifier, ICSI). The user's external ID is not an ID used within the IMS or the mobile carrier network, but rather an ID used externally, for example, in 3 rd It may be a user identifier managed by a party service provider. The user of UE#2 may have decided to send a request message for DC session establishment to the IMS CN and UE#1 via the DC AS / AF when the UE#2 terminal physically or logically does not support the IMS DC service. In this case, the User ID of the UE#2 may include a User ID corresponding to a terminal that supports the IMS DC service of the UE#2 user in the message of step 303, and this User ID may be the same as or different from the User ID of the UE#2 used in the IMS audio call in progress between UE#1 and UE#2 in step 301. The external group ID may be an identifier representing a group that includes one or more users. The users indicated by the group ID may be composed of users who use / subscribe to the same service. The same service may be a service that can be identified by the Service ID included in the DC session setup request message of step 303. User information included in an AF request message may include one or more user identifiers. The group information included in the AF request message may include one or more external group identifiers. The service provided by the IMS AS or the indicator indicating the service provided by the IMS AS may be the IMS Communication Service (ICS Identifier (ICSI)) provided by the IMS AS. Table 1 shows examples of ICSI values. The services provided by the IMS AS may include the IMS DC service. URN-valueBrief overview of the functionality associated with this NSS.urn:urn-7:3gpp-service.ims.icsi.mmtelThis URN indicates that the device supports the IMS Multimedia Telephony Communication Service framework, and specifically indicates that the terminal has the capabilities of multimedia telephonyurn:urn-7:3gpp-service.ims.icsi.iptvExtract from TS 183 063 clause 5.6.1: " This URN indicates that the device supports the IMS IPTV Service"urn:urn-7:3gpp-service.ims.icsi.raExtract from TS 185 010 (draft only) clause A.3: " This URN indicates that the device supports the IMS Remote Access Service"urn:3gpp-service.ims.icsi.omapushThis ICSI value is associated with OMA Push services. The OMA Push 2.2 enabler release, which is in Candidate status in the OMA, includes support for SIP Push. SIP Push extends the OMA Push enabler, which is widely deployed and fundamental to many mobile data services, with the ability to operate over SIP-based networks such as 3GPP IMS.The OMA Push ICSI enables SIP transactions that are related to the OMA Push service to be identified, so that messages can be properly handled by the SIP / IP Core Network functions and OMA Push service entities. Support for SIP Push will be fundamental to the evolution of mobile data services in an LTE environment, as OMA Push service entities can provide seamless evolution for OMA service enablers from dependence upon the SMS-based WAP Push transport, transparently delivering the same service-specific data over SIP Push.urn:urn-7:3gpp-service.ims.icsi.oma.cpm.msgOMA CPM Pager Mode CPM Message : Uniquely identifies in a SIP MESSAGE a Pager Mode CPM Standalone Message.urn:urn-7:3gpp-service.ims.icsi.oma.cpm.largemsgOMA CPM Large Mode CPM Message: Uniquely identifies in SIP INVITE a request for Large Message Mode CPM Standalone Message.urn:urn-7:3gpp-service.ims.icsi.oma.cpm.filetransferOMA CPM File Transfer: Uniquely identifies in SIP INVITE a request for CPM File Transferurn:urn-7:3gpp-service.ims.icsi.oma.cpm.sessionOMA CPM Chat: Uniquely identifies in SIP INVITE a request for CPM chat.urn:urn-7:3gpp-service.ims.icsi.oma.cpm.deferredOMA CPM Deferred Messageurn:urn-7:3gpp-service.ims.icsi.oma.cpm.systemmsgOMA CPM System Message: Uniquely identifies in SIP INVITE a request for a CPM System message.urn:urn-7:3gpp-service.ims.icsi.oma.cab_1.0Used to identify and route message notifications specific for OMA CAB and OMA S-CAB, such as notifications to a user that he / she was added as a new contact by another user.3gpp-service.ims.icsi.oma.cab_1.1Used to identify and route contact subscription invitation requests, using a SIP MESSAGE between two network entities (e.g. cross-domain OMA CAB 1.1 Servers) as defined in OMA CAB 1.1.+g.oma.sip-imIM feature tag used in the Contact header of the SIP REGISTER request to indicate support for OMA SIMPLE IM, and in the Accept-Contact header of:SIP INVITE for SIMPLE IM chat sessions, file transfer, Large Message Mode and deferred delivery of messages, and ofSIP MESSAGE containing a SIMPLE IM Pager Mode Message.+g.oma.sip-im.system-messageIM feature tag used in the Contact header of the SIP REGISTER request to indicate that a IM client supports System Message, and in the SIP MESSAGE requests to distinguish system messages from normal user message.+g.oma.sip-im.large-messageIM feature tag used in the Contact header of the SIP REGISTER request to indicate that a IM client supports Large Message session, and in SIP INVITE to determine that the request is a Large IM Message.urn:urn-7:3gpp-service.ims.icsi.mcpttThis URN indicates that the device has the capabilities to support the mission critical push to talk (MCPTT) service.urn:urn-7:3gpp-service.ims.icsi.mcdataThis URN indicates that the device has the capabilities to support the Mission Critical Data (MCData) service. This URN is also used by the device to associate a SIP request with the Mission Critical Data (MCData) service.urn:urn-7:3gpp-service.ims.icsi.mcdata.sdsThis URN indicates that the device has the capabilities to support the Mission Critical Data (MCData) Short Data Service (SDS) IMS communication service. This URN is also used by the device to associate a SIP request with the Mission Critical Data (MCData) Short Data Service (SDS) IMS communication service.urn:urn-7:3gpp-service.ims.icsi.mcdata.fdThis URN indicates that the device has the capabilities to support the Mission Critical Data (MCData) File Distribution (FD) IMS communication service. This URN is also used by the device to associate a SIP request with the Mission Critical Data (MCData) File Distribution (FD) IMS communication service.urn:urn-7:3gpp-service.ims.icsi.mcvideoThis URN indicates that the device has the capabilities to support the mission critical video (MCVideo) service. 304. DC AS / AF can forward DC Session Setup Request message to IMS AS. 304a. The DC AS / AF can directly send a DC session setup request message to the IMS AS. The DC AS / AF can find the server address of the IMS AS from the information received in step 304 or previously registered in the DC AS / AF. 304b. DC AS / AF can forward DC Session Setup Request message to IMS AS through NEF. 304b-1. DC AS / AF can forward DC Session Setup Request message to NEF. 304b-2. NEF can authenticate the request of DC AS / AF. NEF can verify whether DC AS is NF or AF that can request DC session establishment. NEF can verify whether terminal corresponding to user ID included in AF request message can use requested service, i.e. terminal subscribed to the service. NEF can verify whether user group corresponding to group ID included in AF request message or terminal corresponding to group ID can use requested service, i.e. group or terminal subscribed to the service. NEF can verify whether requested service is related to / corresponding to data channel. If terminal subscription information is required for the above verification / authentication procedure, the NEF may obtain terminal subscription information from the UDM / HSS (not shown). The NEF may transmit a terminal subscription information request message to the UDM / HSS. The terminal subscription information request message may include a terminal ID. The terminal ID may be determined based on the user information received from the DC AS in step 304. For example, the NEF may include the terminal ID received in step 304 in the terminal subscription information request message. Alternatively, for example, the NEF may change the terminal ID (e.g., external ID, etc.) received in step 304 to a terminal ID used in the IMS or mobile communication service provider network (e.g., Public User Identity, Private User Identity, etc.) and include the changed terminal ID in the terminal subscription information request message. Alternatively, for example, NEF may change the group ID received in step 304 to a group ID or terminal ID (e.g., Public User Identity, Private User Identity, etc.) used in the IMS or mobile operator network, and include the changed group ID or terminal ID in the terminal subscription information request message. UDM can reply to NEF with a list of services to which a user is subscribed, referred to by terminal ID or group ID. 304b-3. NEF can forward DC session setup requests to IMS AS. 304b-3-1. NEF can directly forward DC session setup request to IMS AS. NEF can obtain the address of IMS AS from NRF, HSS / UDM, or find it from information registered in advance to NEF. 304b-3-2. NEF can send a DC session setup request to IMS AS through DCSF (data channel signaling function). DCSF can obtain the address of IMS AS from NRF, HSS / UDM, or find it from information registered in advance in DCSF. 305. The IMS AS may request IMS subscriber data for UE#1 by providing the User ID of UE#1 and / or the User ID and / or the Service ID of the User ID of UE#2 to the HSS / UDM. The IMS subscriber data request message may include the User ID of UE#1 and / or the User ID of UE#2. The terminal ID may be determined based on the user information received from the DC AS in step 304. For example, the IMS AS may include the User ID received in step 304 in the message in step 305. Alternatively, for example, the IMS AS may change the User ID (e.g., an external ID, etc.) received in step 304 to a terminal ID used in the IMS or mobile communication service provider network (e.g., Public User Identity, Private User Identity, etc.) and include the changed User ID in the message in step 305. Alternatively, for example, NEF may change the group ID received in step 304 to a group ID or user ID (e.g., Public User Identity, Private User Identity, etc.) used in the IMS or mobile operator network, and include the changed group ID or user ID in the message in step 305. IMS Subscriber data includes IMS subscription data and other data related to the subscriber. For example, it may include NF / network entity address, location information, etc. Table 2 shows examples of IMS Subscriber data types. IMS Subscriber dataDescriptionService Profile DataThis may include eg service parameters, the S-CSCF allocated to a public identity or the list of S-CSCFs and their capabilities, Application Server address, triggers, information on subscribed media, profile parameters (eg barring indicator, etc.) as defined in TS 29.228

[0030] .Service Profile Data is consumed by CSCF.Repository DataData that is understood syntactically but not semantically by the HSS (unstructured Data). It is data that an AS or DCSF may store in the HSS to support its service logic. One example is data that an AS or DCSF stores in the HSS, using it as a repository.Service Indication identifies the set of service related transparent data associated to a Public Identity.Repository Data is consumed by IMS-AS and DCSF.Non-Transparent DataData that is understood both syntactically and semantically by the HSS eg location information. Non-Transparent Data is structured using data references as defined in TS 29.328

[0079] .Non-Transparent Data is consumed by IMS-AS. A Data Key and Data Sub Key may be required to obtain the IMS subscriber data corresponding to each IMS subscriber data type. Table 3 shows an example. IMS Subscriber Data TypesData KeyData Sub KeyService Profile DataPublic IdentityRepository DataPublic IdentityService IndicationNon-Transparent DataSee NOTE 1NOTE 1: TS 29.328

[0079] defines the data keys / subkeys required by each data reference. 306. The HSS / UDM may provide the IMS AS with IMS subscriber data for UE#1. The IMS subscriber data may include repository data for the IMS DC service. 307. The IMS AS may determine whether to send a DC session setup request to UE#1 based on the DC session setup request message received in step 304 and the information included in the IMS subscriber data received in step 306. For example, if the IMS subscriber data for UE#1, or UE#1 and UE#2, includes repository data for the IMS DC service, it may be determined that UE#1 is a UE that supports the IMS DC service, and thus may determine to send a DC session setup request to UE#1. The IMS AS may generate a SIP message including the DC session request message. The SIP message may use a SIP INFO message or a SIP MESSAGE message. An entity that receives a SIP INFO message can send a Response message to the SIP INFO, and an entity that receives a SIP MESSAGE message does not need to send a Response message. 308. The IMS AS may send a SIP INFO or SIP MESSAGE message containing a DC session setup request to the S-CSCF. 309. The S-CSCF may request IMS subscriber data for UE#1 and / or UE#2 by providing the User ID of UE#1 and / or the User ID of UE#2 to the HSS / UDM. 310. HSS / UDM may provide IMS subscriber data for UE#1 to S-CSCF. The IMS subscriber data may include service profile data for IMS DC service. 311. The S-CSCF may determine whether to transmit a DC session setup request to UE#1 based on the DC session setup request message received in step 308 and the information included in the IMS subscriber data received in step 310. For example, if the IMS subscriber data for UE#1 includes service profile data for an IMS DC service, it may be determined that UE#1 is a UE supporting the IMS DC service, and thus may determine to transmit a DC session setup request to UE#1. The S-CSCF may generate a SIP message including the DC session request message and transmit it to the UE, or forward the message received in step 310 to the UE. 312. UE#1 can check whether it supports IMS DC service. UE#1 can determine whether it supports IMS DC service and initiate DC setup request procedure based on information included in DC session setup request. UE#1 can identify ongoing IMS audio call with UE#2 based on information included in DC session setup request. UE#1 can decide to add DC session to ongoing IMS audio call with UE#2. UE#1 can decide to send SIP message (e.g., SIP re-INVITE message) to add DC session to ongoing IMS audio call with UE#2. 313. UE#1 can send a response to step 311 or a result of delivery of the DC session setup request message to the S-CSCF. If a SIP INFO message is received in step 311, a Response message to SIP INFO can be sent, and if a SIP MESSAGE is received, a SIPI MESSAGE can be sent. The result of the DC session setup request delivery can include success or failure. When providing a result of failure, a cause of failure can be additionally provided. 314. The S-CSCF may send a message (e.g., a response message to step 308 or a separate SIP message) to the IMS AS containing the result of delivery of the DC Session Setup Request message. 314a. In S-CSCF steps 309 to 311, if the IMS subscriber data for UE#1 does not include service profile data for the IMS DC service, it may determine that UE#1 is a UE that does not support the IMS DC service, and thus decide not to perform step 311. In this case, the S-CSCF may provide the reason for the failure that UE#1 did not have DC service subscription information, along with the result of the failure. 314b. The S-CSCF may have received the result of failure and / or the reason for failure from UE#1 in step 313 and may forward this to the IMS AS. 314.c The S-CSCF may have received a success result from UE#1 in step 313 and may forward it to the IMS AS. 315. UE#1 may send a SIP re-INVITE message containing an SDP offer for establishing a Bootstrap DC session with UE#2 based on its decision to add a DC session to the ongoing IMS audio call with UE#2 in step 312. This message may be forwarded to the IMS AS via P-CSCF, I-CSCF / S-CSCF. 316. The IMS AS may transmit a response to step 304 or a delivery result of the DC Session Establishment Request message to the DC AS / AF. The IMS AS may deliver the delivery result of the DC Session Establishment Request message received in step 314 to the AF. (1) If the IMS subscriber data for UE#1 does not include storage data for the IMS DC service in step 307, the IMS AS may determine that UE#1 is a UE that does not support the IMS DC service and thus may decide not to perform step 308. In this case, the IMS AS may provide a failure result along with the reason that UE#1 did not have DC service subscription information. (2) If the IMS AS does not receive the message of step 314 for a certain period of time and also does not receive the message of step 315, the IMS AS may provide a failure result with a reason that the UE did not respond (UE not response). The UE did not respond may include that the UE is not reachable. (3) If the IMS AS does not receive the message of step 314 for a certain period of time, but receives the message of step 315, the IMS AS can provide a success result. 316a. An IMS AS can provide the DC AS / AF with the result of the delivery of a DC Session Setup Request message directly. 316b. The IMS AS can provide the DC AS / AF with the result of delivery of the DC Session Setup Request message via NEF. 316b-1. An IMS AS can provide the NEF with the result of delivery of a DC Session Setup Request message. 316b-1-1. IMS AS provides directly to NEF, or 316b-1-2. Can be provided to NEF through DCSF. 316b-2. NEF can provide the DC AS / AF with the result of delivery of the DC Session Setup Request message. 317. The DC AS / AF may send a response to step 303 or the result of delivery of the DC Session Setup Request message to UE#2. 318. Following step 315, the Bootstrap DC session setup procedure may be performed. 319. Following step 318, the Application DC session setup procedure may be performed. FIG. 4a and FIG. 4b illustrate a method for providing an IMS DC service in a communication system according to one embodiment of the present disclosure. The description for steps 401 and 402 is identical to the description for steps 301 and 302 of FIG. 3a. 403. UE#2 may decide to request the establishment of a DC session to the IMS AS via the S-CSCF (or I-CSCF). UE#2 may send the DC session establishment request to the S-CSCF using a SIP INFO or SIP MESSAGE message. The user of UE#2 may have decided to send a request message for DC session setup to the IMS CN and UE#1 via the DC AS / AF when the UE#2 terminal physically or logically does not support the IMS DC service. In this case, the User ID of the UE#2 may include a User ID corresponding to a terminal that supports the IMS DC service of the UE#2 user in the message of step 403, and this User ID may be the same as or different from the User ID of the UE#2 used in the IMS audio call in progress between UE#1 and UE#2 in step 401. The external group ID may be an identifier representing a group that includes one or more users. The users indicated by the group ID may be composed of users who use / subscribe to the same service. The same service may be a service that can be identified by the Service ID included in the DC session setup request message of step 403. User information included in an AF request message may include one or more user identifiers. The group information included in the AF request message may include one or more external group identifiers. The service provided by the IMS AS or the indicator representing the service provided by the IMS AS may be an IMS Communication Service (ICS Identifier (ICSI)) provided by the IMS AS. 404. The S-CSCF may forward a DC session setup request to the IMS AS. The description of steps 405 to 415 of FIG. 4 is identical to the description of steps 305 to 315 of FIGS. 3a, 3b and 3c. 416. The IMS AS may send to the S-CSCF a response to step 404 or the result of delivery of the DC Session Setup Request message. 417. The S-CSCF may send a response to step 403 or the result of delivery of the DC Session Setup Request message to UE#2. The description for steps 418 and 419 of FIG. 4 is identical to the description for steps 318 and 319 of FIG. 3c. FIGS. 5a and 5b illustrate a method for providing an IMS DC service in a communication system according to an embodiment of the present disclosure. The description for step 501 is identical to the description for step 301 of Fig. 3a. 502. UE#2 may determine that it needs to additionally set up an IMS DC call to the ongoing IMS audio call with UE#1. UE#2 may determine that it needs to check whether UE#1 is a UE that supports the IMS DC service before deciding to additionally set up an IMS DC call, and for this purpose, it may perform the procedures below step 503. 503. UE#2 can request information necessary to check whether UE#1 supports DC service by using an event exposure subscription (or subscription) message to NEF. The event exposure subscription message can include event parameter information on whether UE supports DC service, at least one of User ID (e.g. Public Identifier) of UE#1, and Service ID. 503a. UE#2 can make requests directly to NEF. 503b. UE#2 can request NEF through DC AS / AF. 504. NEF can authenticate the request of DC AS / AF or UE#2. NEF can verify whether DC AS is NF or AF capable of DC session establishment request. NEF can verify whether terminal corresponding to user ID included in AF request message is able to use requested service, i.e. terminal subscribed to the service. NEF can verify whether user group corresponding to group ID included in AF request message or terminal corresponding to group ID is able to use requested service, i.e. group or terminal subscribed to the service. NEF can verify whether requested service is related to / corresponding to data channel. If terminal subscription information is required for the above verification / authentication procedure, the NEF may obtain terminal subscription information from the UDM / HSS (not shown). The NEF may transmit a terminal subscription information request message to the UDM / HSS. The terminal subscription information request message may include a terminal ID. The terminal ID may be determined based on the user information received from the DC AS in step 504. For example, the NEF may include the terminal ID received in step 504 in the terminal subscription information request message. Alternatively, for example, the NEF may change the terminal ID (e.g., external ID, etc.) received in step 504 to a terminal ID used in the IMS or mobile communication service provider network (e.g., Public User Identity, Private User Identity, etc.) and include the changed terminal ID in the terminal subscription information request message. Alternatively, for example, NEF may change the group ID received in step 504 to a group ID or terminal ID (e.g., Public User Identity, Private User Identity, etc.) used in the IMS or mobile operator network, and include the changed group ID or terminal ID in the terminal subscription information request message. UDM can reply to NEF with a list of services to which a user is subscribed, referred to by terminal ID or group ID. 505. NEF may forward an event exposure subscription message to IMS AS to check whether UE#1 supports DC service. 505a. NEF can directly forward the event exposure subscription message to IMS AS for checking whether UE#1 supports DC service. NEF can obtain the address of IMS AS from NRF, HSS / UDM, or find it from information registered in advance in NEF. 505b. NEF can be delivered to IMS AS via DCSF. DCSF can obtain the address of IMS AS from NRF, HSS / UDM, or find it from information registered in advance in DCSF. 506. The IMS AS may request IMS subscriber data for UE#1 by providing the HSS / UDM with the user ID and / or service ID of UE#1. 507. HSS / UDM may provide IMS subscriber data for UE#1 to IMS AS. IMS subscriber data may include repository data for IMS DC service. 508. The IMS AS may send a notification message for step 505 based on the information included in the IMS subscriber data received in step 507. The notification message may include at least one of event information on whether the UE supports the DC service (e.g., supported or not supported), User ID of UE#1 (e.g., Public Identifier), and Service ID. 508a. IMS AS may notify NEF directly. 508b. IMS AS may notify through DCSF. 509. NEF may send a notification message for step 503. NEF may forward the notification message received in step 508 to UE#2. 509a. NEF may notify UE#2 directly. 509b. NEF may notify through DC AS / AF. 510. UE#2 may decide to additionally set up an IMS DC call to the ongoing IMS audio call with UE#1 based on the notification information received in step 510. For example, if the notification message of step 510 reports that UE#1 does not support the IMS DC service, UE#2 may decide not to add a DC session and may not perform procedures below step 511. Alternatively, if the notification message of step 510 reports that UE#1 supports the IMS DC service, UE#2 may decide to add a DC session and perform procedures below step 511. 511. UE#2 may send a SIP re-INVITE message containing an SDP offer for Bootstrap DC session establishment to UE#1 based on its decision to add a DC session to the ongoing IMS audio call with UE#1 in step 510. Accordingly, a Bootstrap DC session establishment procedure may be performed between UE#1 and UE#2. 512. Following step 511, the Application DC session setup procedure may be performed. FIGS. 6a and 5b illustrate a method for providing an IMS DC service in a communication system according to an embodiment of the present disclosure. The description of steps 601 to 604 of FIG. 6a is the same as the description of steps 501 to 504 of FIG. 5a. 605. NEF may forward an event exposure subscription message to S-CSCF for checking whether UE#1 supports DC service. 605a. NEF can pass the address of S-CSCF directly. NEF can obtain the address of S-CSCF from NRF, HSS / UDM, or find it from information registered in advance in NEF. 605b. NEF can be delivered to S-CSCF through IMS AS. NEF can obtain the address of IMS AS from NRF, HSS / UDM, or find it from information registered in advance in NEF. 605c. NEF can be delivered to S-CSCF through DCSF, through IMS AS. DCSF can obtain the address of IMS AS from NRF, from HSS / UDM, or from information registered in advance in DCSF. 606. S-CSCF may request IMS subscriber data for UE#1 by providing the user ID of UE#1 to HSS / UDM. 607. HSS / UDM may provide IMS subscriber data for UE#1 to IMS AS. IMS subscriber data may include service profile data for IMS DC service. 608. The S-CSCF may send a notification message for step 605 based on the information contained in the IMS subscriber data received in step 607. 608a. S-CSCF may notify NEF directly. 608b. S-CSCF may notify NEF via IMS AS. 608c. S-CSCF may notify NEF through DCSF via IMS AS. The description of steps 609 to 612 of FIG. 6b is identical to the description of steps 509 to 512 of FIG. 5b. FIG. 7 illustrates a block diagram of a device according to one embodiment of the present disclosure. The device (700) may implement any of the entities described in the present disclosure. For example, the device (700) may implement one of the illustrated UEs and multiple NFs described through FIGS. 1 to 6. The device may include at least one processor (710), a transceiver (720), and a memory (730). At least one processor (710) may be coupled to other elements within the device (700), such as the transceiver (720), and the memory (730), to control the operation of the other elements. The at least one processor (710) may control itself and other elements of the device (700) to cause the device (700) to perform at least one operation. The operation of the device (700) may be interpreted as being substantially executed by the at least one processor (710). The transceiver (720) may include circuitry required for communication (i.e., communication circuitry). The device (700) may communicate with other devices through the transceiver (720). The transceiver (720) may support at least one of various wireless access technologies such as, but not limited to, LTE (long term evolution), LTE-A (LTE-Advanced), CDMA (code division multiple access), OFDM (orthogonal frequency division multiplexing), Bluetooth, etc. The transceiver (720) may provide communication capabilities to the device (700) using any known wireless access technologies. The memory (730) may be referred to as a 'non-transitory computer readable storage medium' to be distinguished from a medium for transmitting information. The memory (730) may be implemented through at least one of a random access memory (RAM), a read-only memory (ROM), a hard disk, a CD-ROM, and a solid state drive (SSD), but is not necessarily limited thereto and may be implemented through all types of possible storage media capable of storing and reading information. The memory (730) may store instructions executable by at least one processor (710). When the instructions are executed by at least one processor (710), at least one processor (710) (or the device (700)) may execute at least one of the operations of the device (700) described in the present disclosure. The memory (730) may also store temporary or permanent data necessary for the operation of at least one processor (710). Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are only specific examples to easily explain the technical content of the present disclosure and help understand the present disclosure, and are not intended to limit the scope of the present disclosure. That is, it will be apparent to a person having ordinary skill in the art to which the present disclosure pertains that other modified examples based on the technical idea of the present disclosure are possible. In addition, each of the above embodiments can be combined and operated with each other as needed. For example, parts of one embodiment of the present disclosure and another embodiment can be combined with each other to operate a base station and a terminal. In addition, other modified examples based on the technical idea of the above embodiments can be implemented in various systems such as an FDD LTE system, a TDD LTE system, a 5G or NR system.

Claims

1. A method for providing IMS (IP Multimedia Subsystem) data channel (DC) service by NEF (network exposure function). A step of receiving a first request from a data channel (DC) application server (AS) to add or remove a DC to an existing IMS session; A step of querying a home subscriber server (HSS) to identify an IMS AS for a user equipment (UE); and Comprising the step of transmitting a second request to the identified IMS AS to add or remove a DC to the existing IMS session, method.

2. In paragraph 1, The step of querying the HSS includes the step of transmitting a message including a private identity of the UE to the HSS. method.

3. In paragraph 1, The above DC is a bootstrap DC, method.

4. In paragraph 1, Further comprising the step of receiving a response to the second request for adding or removing a DC to the IMS session from the identified IMS AS. method.

5. In paragraph 4, If the above response indicates a failure, the response includes information indicating the cause of the failure. method.

6. In paragraph 4, Further comprising the step of transmitting the received response to the DC AS; method.

7. As a device for NEF (network exposure function) to provide IMS (IP Multimedia Subsystem) data channel (DC) service, Transmitter and receiver; and At least one processor coupled to the transceiver, wherein the at least one processor comprises: Receives a first request from a Data Channel (DC) Application Server (AS) to add or remove a DC to an existing IMS session, Query the home subscriber server (HSS) to identify the IMS AS for the user equipment (UE); and configured to transmit a second request to the identified IMS AS to add or remove a DC to the existing IMS session; device.

8. In paragraph 7, The at least one processor is configured to transmit a message including a private identity of the UE to the HSS to query the HSS. device.

9. In paragraph 7, The above DC is a bootstrap DC, device.

10. In paragraph 7, The at least one processor is further configured to receive a response to the second request to add or remove a DC to the IMS session from the identified IMS AS. device.

11. In clause 10, If the above response indicates a failure, the response includes information indicating the cause of the failure. device.

12. In paragraph 10, wherein said at least one processor is further configured to transmit said received response to said DC AS; device.

Images