Method and apparatus for supporting data channel interworking in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. An operation method of an IP multimedia subsystem application server (IMS AS) in a wireless communication system, according to the present disclosure, may comprise the steps of: receiving, from a first user equipment (UE), a request message that requests to establish, as a peer-to-peer (P2P) application data channel, an application data channel with a second UE; transmitting, to a data channel server function (DCSF), a session event control notify message comprising information about the P2P application data channel; receiving, from the DCSF, a message comprising change indication information indicating to change the P2P application data channel to a person-to-application (P2A) application data channel; and changing an endpoint of the application data channel to an endpoint of a server, on the basis of the change indication information.

Description

Method and apparatus for supporting data channel interworking in a wireless communication system

[0001] The present disclosure relates to a method and apparatus for supporting data channel interworking for using an IMS data channel service between an MTSI (multimedia telephony service for IMS (internet protocol multimedia subsystem)) UE (user equipment) and a DCMTSI (data channel MTSI) UE in a wireless communication system.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands that meets various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field 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) which provides nodes to expand 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 Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] A method of operation of an IP Multimedia Subsystem Application Server (IMS AS) in a wireless communication system according to one embodiment of the present disclosure may include: receiving a request message from a first UE (user equipment) requesting to establish an application data channel with a second UE as a Peer-to-Peer (P2P) application data channel; transmitting a session event control notification message containing information about the P2P application data channel to a Data Channel Server Function (DCSF); receiving a message from the DCSF containing change instruction information instructing to change the P2P application data channel to a Person-to-Application (P2A) application data channel; and changing the endpoint of the application data channel to the endpoint of a server based on the change instruction information.

[0009] A method of operation of a Data Channel Server Function (DCSF) in a wireless communication system according to one embodiment of the present disclosure may include: receiving a session event control notification message from an IP Multimedia Subsystem Application Server (IMS AS) containing information about a Peer-to-Peer (P2P) application data channel between a first UE and a second UE; determining to change the P2P application data channel to a Peer-to-Application (P2A) application data channel based on at least one of application information about the application data channel or information about the second UE; and transmitting a message to the IMS AS containing change instruction information instructing to change the P2P application data channel to the P2A application data channel, wherein, based on the change instruction information, the endpoint of the P2P application data channel is changed to an endpoint of a server by the IMS AS.

[0010] According to one embodiment of the present disclosure, in a wireless communication system, an IP Multimedia Subsystem Application Server (IMS AS) comprises at least one processor and at least one memory that is communicationally coupled to the at least one processor and stores instructions, wherein the instructions are executed individually or in any combination by the at least one processor, and the IMS AS receives a request message from a first UE (user equipment) requesting that an application data channel with a second UE be established as a Peer-to-Peer (P2P) application data channel, transmits a session event control notification message containing information about the P2P application data channel to a Data Channel Server Function (DCSF), receives a message from the DCSF containing change instruction information instructing to change the P2P application data channel to a Person-to-Application (P2A) application data channel, and based on the change instruction information, can change the endpoint of the application data channel to the endpoint of a server.

[0011] According to one embodiment of the present disclosure, in a wireless communication system, the Data Channel Server Function (DCSF) comprises at least one processor; The DCSF may include at least one memory that is communiquently coupled to the at least one processor and stores instructions, wherein the instructions are executed individually or in any combination by the at least one processor, and the DCSF receives a session event control notification message from an IMS AS (IP Multimedia Subsystem Application Server) containing information about a P2P (Peer-to-Peer) application data channel between a first UE and a second UE, and determines to change the P2P application data channel to a P2A (Peer-to-Application) application data channel based on at least one of application information about the application data channel or information about the second UE, and transmits a message containing change instruction information instructing the IMS AS to change the P2P application data channel to the P2A application data channel, and based on the change instruction information, the endpoint of the P2P application data channel is changed to the endpoint of the server by the IMS AS.

[0012] A method and apparatus according to one embodiment of the present disclosure provide an operation and apparatus for changing application data channel-related information transmitted from a terminal to support DC interworking using a DC AS.

[0013] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0014] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following description of embodiments of the present disclosure with reference to the accompanying drawings.

[0015] FIG. 1a is a diagram illustrating the network structure and interface of a 5G system according to one embodiment of the present disclosure.

[0016] FIG. 1b is an example of an IMS-DC (IP (Internet Protocol) Multimedia Subsystem Data Channel) structure providing an IMS (IP (Internet Protocol) Multimedia Subsystem) service-based data channel service according to one embodiment of the present disclosure.

[0017] FIG. 2a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0018] FIG. 2b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0019] FIG. 3a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0020] FIG. 3b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0021] FIG. 4a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0022] FIG. 4b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0023] FIG. 5a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0024] FIG. 5b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0025] FIG. 6a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0026] FIG. 6b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to one embodiment of the present disclosure.

[0027] FIG. 7 illustrates the structure of a terminal according to one embodiment of the present disclosure.

[0028] FIG. 8 illustrates the structure of a base station according to one embodiment of the present disclosure.

[0029] FIG. 9 illustrates the structure of a network entity according to one embodiment of the present disclosure.

[0030] Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the attached drawings.

[0031] In describing the present disclosure, technical details 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 intended to convey the essence of the present disclosure more clearly without obscuring it by omitting unnecessary explanations. Furthermore, the terms described below are defined considering their functions within the present disclosure, and these definitions may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0032] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the dimensions of each component do not entirely reflect their actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0033] Hereinafter, a base station (BS) is an entity that performs resource allocation for terminals and may be at least one of gNode B, eNode B, Node B (or xNode B (where x is an alphabet including g and e)), a radio access unit, a base station controller, a satellite, an airborn, or a node on a network. A terminal (user equipment: UE) may include a Mobile Station (MS), a Vehicular, a satellite, an airborn, a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions. In this disclosure, a downlink (DL) refers to a radio transmission path for a signal transmitted by a base station to a terminal, and an uplink (UL) refers to a radio transmission path for a signal transmitted by a terminal to a base station. Additionally, a sidelink (SL) may exist, which refers to a radio transmission path for a signal transmitted by a terminal to another terminal.

[0034] In addition, while LTE, LTE-A, or 5G systems may be described below as examples, embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, 5G-Advance or NR-Advance or 6th generation mobile communication technology (6G) developed after 5G mobile communication technology (or new radio, NR) may be included, and the 5G below may be a concept that includes existing LTE, LTE-A, and other similar services. Furthermore, the present disclosure may be applied to other communication systems with some modifications made at the discretion of a person with skilled technical knowledge, without significantly departing from the scope of the present disclosure.

[0035] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0036] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0037] In this embodiment, the term "part" refers to a software or hardware component such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run 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, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within 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 utilize one or more CPUs within the device or secure multimedia card. Also, in the embodiments, 'parts' may include one or more processors.

[0038] 3GPP, responsible for cellular mobile communication standards, has named a new core network structure "5G Core" (5GC) and is proceeding with standardization to facilitate the evolution from 4G LTE systems to 5G systems. Compared to the Evolved Packet Core (EPC), the network core for 4G, 5GC supports the following differentiated features.

[0039] Network Slice functionality is introduced in 5GC. As a requirement for 5G, 5GC must support various types of terminals and services; e.g., enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLC), and Massive Machine Type Communications (mMTC). Each of these terminals / services has different requirements for the core network. For instance, eMBB services may require high data rates, while URLLC services may require high stability and low latency. Network Slice technology has been proposed to satisfy these diverse service requirements.

[0040] Network slicing refers to a method of creating multiple logical networks (e.g., network slices) by virtualizing a single physical network. An active network slice can be referred to as a network slice instance, and each network slice instance (NSI) can have different characteristics. Mobile operators can satisfy various service requirements for terminals / services by configuring network functions (NFs) suited to the characteristics of each NSI. For example, mobile operators can efficiently support various 5G services (e.g., eMBB, URLLC, or mMTC) by allocating an NSI that matches the characteristics of the service required by each terminal.

[0041] 5GC facilitates support for network virtualization paradigms by separating mobility management functions and session management functions. In 4G LTE, all terminals receive services from the network through signaling exchanges with a single core entity called the Mobility Management Entity (MME), which is responsible for registration, authentication, mobility management, and session management functions. In 5G, as the number of terminals (e.g., MTC terminals) increases explosively and the mobility and traffic / session characteristics that must be supported vary depending on the terminal type, having a single entity (e.g., MME) support all functions inevitably leads to reduced scalability, which requires adding entities for specific functions. Therefore, to improve scalability in terms of the functional / implementation complexity and signaling load of the core entity responsible for the control plane, various functions are being developed based on a structure that separates mobility management functions and session management functions.

[0042] The IMS system (IP (Internet Protocol) Multimedia Subsystem) is a system for transmitting IP-based multimedia, and various services such as VoLTE and VoNR are provided through existing IMS networks linked with LTE or 5G networks. The purpose of the IMS data channel service is to provide various additional services, such as user location information transmission and screen sharing using separate applications, in addition to existing voice or video-based services, by utilizing data channel services linked with IMS in addition to existing RTP (Real-Time Transport Protocol)-based services such as voice, video, and text. The data channel service linked with IMS may be an IMS-DC (IP (Internet Protocol) Multimedia Subsystem-Data Channel) service.

[0043] In order to use an additional service or a standalone IMS data channel service using an IMS data channel within the IMS data network, the terminal can transmit a signaling message to the network that includes a request for a data channel application and related configuration information for a data channel-based service through a bootstrap data channel setup signaling process. Upon receiving the signaling message, the IMS data channel network can transmit application or application list information to the terminal based on the settings of the user or service provider and the request information received from the terminal, thereby enabling the download of an application for the data channel service.

[0044] Based on application or application list information received from the network, the terminal can select an appropriate data channel application according to the terminal's performance and user selection, and request the corresponding data channel application. Additionally, the network may allocate a separate media function entity within the network during the bootstrap data channel setup process to support the download of a specific application requested by the terminal. The media function entity may receive data channel application-related information (Replacement HTTP URL representing the application list offered via the MDC1 interface) that can be converted into data channel application information through the operation of a media resource management service during the bootstrap data channel setup process.

[0045] Subsequently, the media function entity receives specific data channel application information selected and requested by the terminal through the Mb interface, converts the data channel application download request information into HTTP URL information recognizable by the IMS data channel network (e.g., DSCF), and performs the terminal's application download support operation.

[0046] The terminal can receive each data channel application through a bootstrap connection process and can receive information related to the data channel application simultaneously with the reception of the data channel application. Subsequently, the terminal can perform an application data channel setup signaling operation to request a data channel connection for the received data channel application. The application data channel setup signaling message may also transmit application binding information containing configuration information to support a specific application. Based on the information received from the terminal, the network can perform at least one application data channel connection operation among three types of application data channel connections: a connection between terminals (P2P (peer-to-peer) Application Data Channel Setup), a connection between terminals and an application server (P2A (peer-to-application or person-to-application) Application Data Channel Setup), or a connection between terminals through an application server (P2A2P (peer-to-application to peer or person-to-application to person) Application Data Channel Setup).

[0047] In accordance with the requirements of the user, the present disclosure describes various embodiments through which DC interworking operations—that is, modification or conversion of DC application data transmitted to terminals that do not support IMS DC services (e.g., MTSI UE) and terminals that do not want IMS DC services—may occur in order to support IMS DC services. In this case, if the modification or conversion of DC application data is performed directly by the operator server via DC AS, UE #1 may need to perform a P2A ADC connection request instead of the existing P2P ADC connection. However, since the decision to perform DC interworking operations via the said DC AS may depend on the operator's settings or network status, UE #1 may not know which type of ADC to request. Therefore, UE #1 transmits a P2P ADC connection request to the network, including information about UE #2 (e.g., IMPU of UE #2), to request an IMS DC connection with the Peer UE (UE #2), and the network may determine a method for performing DC interworking (e.g., DC interworking using MF or DC interworking using DCAS) based on the service provider's settings or network status. The present disclosure provides an information management method and apparatus for transmitting DC application information to a DC AS when selecting a method to perform DC interworking based on a P2P ADC connection request including information of UE #2 transmitted by UE #1 (e.g., IMPU of UE #2).

[0048] According to one embodiment of the present disclosure, when connecting to the IMS DC service, a user using a terminal that supports the IMS DC service may request an IMS DC service with a user using an existing terminal that does not support the IMS DC service.

[0049] For example, a user using a terminal (DCMTSI UE) that supports IMS DC services may request to use an additional service using IMS DC services (e.g., screen sharing) while using an existing IMS service (e.g., voice and / or video call) with a user using an existing terminal (MTSI UE) that does not support IMS DC services.

[0050] To request the use of an additional service utilizing an IMS DC service (e.g., stream sharing), a user using a DCMTSI UE may send a Bootstrap DC session connection request message. Upon receiving the Bootstrap DC-related SDP offer, if the terminal does not support the data channel service, the MTSI UE may forward the Bootstrap DC-related information to the Originating network with the port information within the SDP answer set to 0. If the user of the Terminating UE does not accept the connection request for the IMS DC service, the Terminating UE may set the port information within the Bootstrap DC-related SDP answer forwarded to the Originating network to 0. Through this process, the DCSF (Data channel Signaling function) or IMS AS can determine whether the Terminating network / terminal supports or allows the DC service.

[0051] A terminal supporting the IMS DC service can receive the relevant DC application and application-related information (application binding information) from the DCSF after establishing a Bootstrap DC session.

[0052] Subsequently, a terminal supporting the IMS DC service can transmit an Application DC (ADC) connection request to the network using the DC application received via the BDC connection. Within the ADC connection request message, a P2P ADC session connection request containing information about the counterparty Peer UE (e.g., UE #2) can be transmitted to the network. Upon receiving the P2P ADC session connection request from UE #1, the DCSF checks whether the corresponding DC application supports DC interworking and whether the user possesses subscription information that enables DC interworking; if these conditions are satisfied, the DCSF can decide to support the IMS DC service through DC interworking. If it is decided to support DC interworking in the above step, the DCSF can perform the operation of creating and transmitting media resource settings within the MF to support DC interworking. The media resource setting information for supporting DC interworking may include Originating side settings and Terminating side settings to support the operation of converting information transmitted from the DC application of the terminal supporting the IMS DC service (e.g., DCMTSI UE or UE #1) into a format supported by the MTSI UE (e.g., RTP). For example, to transmit stream sharing information delivered through a DC application transmitted from UE #1 to UE #2, the MF can convert the stream sharing information within the DC application into a video format and transmit it to UE #2. To support the above conversion operation, the MF may additionally request codec information and media information supported by UE #2. The media transformation or converting operation within the DC application can be performed by the MF or by the DC AS, i.e., the service provider server, depending on the settings of the data channel service provider.As described above, if one user refuses to use the DC service between an MTSI UE and a DCMTSI UE or between DCMTSI UEs, the use of the IMS DC service between each user can be supported through the modification of media information transmitted from an intermediate MF or DC AS.

[0053] According to one embodiment of the present disclosure, a method of an IMS AS (Application Server) entity comprises: receiving a session connection request (SIP re-INVITE) message containing an application-related session description protocol (SDP) offer and a video or audio-related session description protocol (SDP) offer in a bootstrap or application data channel session connection request message for using an IMS DC service, transmitted from a terminal supporting an IMS DC (e.g., DCMTSI UE) via an S-CSCF (serving-call session control function); transmitting the application-related session description protocol information within the session connection request message received from the terminal to a DCSF; and transmitting from the DCSF to a terminating side UE (e.g., UE#2) a session connection request (SIP re-INVITE) message containing an application-related session description protocol (SDP) offer and a video or audio-related session description protocol (SDP) offer in a session description protocol, which is updated to support the IMS DC service. A step of receiving from the Terminating side network application-related session description protocol (SDP) answer transmitted from the Terminating side network and terminal, and session description protocol (SDP) response information related to video or audio currently in service;A step of determining that the Terminating UE does not support the IMS DC service or refuses to use the IMS DC service based on application-related session description protocol (SDP) answer information transmitted from the Terminating network and terminal; a step of receiving specific DC application information supporting DC interworking and a request to subscribe to the corresponding event from the DC AS, i.e., the operator server; a step of determining that an application data channel service request event has occurred using a DC application supporting DC interworking based on information within the application-related session description protocol (SDP) offer within the application data channel session connection request message transmitted from the terminal; a step of transmitting an event notification message to the NEF to convey the occurrence of the event to the DC AS; a step of determining that DC interworking is required based on DC application information (e.g., DC Application ID) within the application data channel request message and application-related session description protocol (SDP) answer information received from the Terminating network and terminal; a step of determining whether to perform DC interworking using the DC AS according to the configuration information of the data channel service provider. A step of determining an action to change the Endpoint information set to the terminal to the server based on whether DC interworking using DC AS is performed, using the P2P ADC connection request within the application-related information (a=3gpp-req-app) within the application-related session description protocol (SDP) offer in the data channel application connection request message transmitted by the terminal;If it is decided to change the Endpoint information within the application-related session description protocol (SDP) offer, a step of updating media information transmitted to the DCSF based on the changed Endpoint information; a step of performing an operation to update a session connection request message, wherein the application-related session description protocol (SDP) offer information within the session connection request message transmitted by the originating terminal is removed or the application-related session description protocol (SDP) offer information is set to 0, depending on whether the terminating terminal supports and accepts the IMS DC service connection received during the bootstrap data channel stage; a step of transmitting the session connection request message transmitted by the originating terminal, which has been changed or updated, to the terminating network and terminal; a step of receiving a session description protocol response (SDP answer) transmitted by the terminating terminal; a step of performing additional operations of the above; and a step of receiving the result of the application data channel operation from the DCSF based on the P2A ADC when performing additional operations on the application-related session description protocol response (SDP answer). The step of modifying or updating a response message received from the Terminating side network and terminal to deliver to the Originating side UE an application-related session description protocol (SDP) answer, in which Endpoint information is changed from the server to the terminal based on application-related information within the session description protocol (SDP) offer initially requested by the Originating side UE, as a result of the P2A ADC connection operation received from the DCSF; and the step of delivering a response message for the updated application data channel creation request to the Originating side UE.

[0054] A method of a DCSF (Data channel Signaling function) entity according to one embodiment of the present disclosure comprises: receiving an IMS DC service connection request event and related information transmitted to an IMS AS from a terminal supporting an IMS DC (e.g., DCMTSI UE); if the IMS AS receives DC interworking related information from the DC AS, receiving an IMS DC service connection request event and related information including said DC interworking related information; upon receiving a bootstrap data channel connection request event, generating media resource information to provide the download of the corresponding data channel application and data channel application binding information to each terminal, and transmitting the generated information to the IMS AS to transmit it to the MF; receiving response information regarding a media resource configuration request within the MF from the IMS AS; and transmitting to the IMS AS, based on the received bootstrap data channel related media resource response message, that the bootstrap data channel configuration has been completed, and transmitting a session event response message to the IMS AS for transmitting an application-related session description protocol (SDP) offer for a bootstrap data channel connection request to the terminating side network and terminal. A step of receiving data channel session connection request response information from the terminating side network and terminal as an IMS AS, wherein the port information within the application-related session technical protocol response (SDP answer) information is set to 0; a step of determining whether DC interworking is supported based on the data channel session connection request response information of the terminating network and terminal;If DC interworking is supported according to operator policy or service provider settings, a step of performing an MF media resource update operation containing only the media resources for the Originating-side bootstrap data channel session connection, after deleting the Terminating-side bootstrap data channel media resources; a step of transmitting the MF media resources containing only the media resources for the Originating-side bootstrap data channel session connection to the IMS AS; a step of transmitting a response message for a bootstrap data channel connection request to the Originating-side terminal based on the updated media resource information; a step of determining whether DC interworking is supported based on information regarding data channel support or permission received from the Terminating-side network and terminal during the bootstrap data channel session connection operation, and application information within the application data channel session connection request message requested by the Originating-side terminal; a step of receiving user subscriber information of the corresponding Originating-side terminal from the HSS to determine whether DC interworking is supported; a step of determining the establishment of an application data channel session based on DC interworking based on the subscriber information received from the HSS, the data channel session response message of the Terminating-side terminal, and application-related information (e.g., Application ID) within the application data channel session request message transmitted by the Originating-side terminal. A step of determining a network entity that supports DC interworking based on the service provider's policy or network status information; a step of determining the creation of media resource information and policies based on the determined network entity information; if DC interworking using MF is supported, the DCSF creates a media resource within the MF and transmits the media resource information for supporting DC interworking to the IMS AS.If DC interworking using DC AS is supported, the DCSF includes the steps of: requesting the creation of MDC2 interface information when creating media resources within the MF; transmitting the MDC2 interface information received from the MF to the DC AS; receiving the MDC2 interface information on the DC AS side from the DC AS; transmitting the updated media resources within the MF to the IMS AS based on the MDC2 interface information received from the DC AS; and transmitting the result information of establishing the P2A application data channel session to the IMS AS after performing the creation of the MDC2 interface between the MF and the DC AS.

[0055] FIG. 1a is a diagram illustrating the network structure and interface of a 5G system according to one embodiment of the present disclosure.

[0056] The network entity included in the network structure of the 5G system of Fig. 1a may include a network function (NF) depending on the system implementation.

[0057] Referring to Fig. 1a, the network structure of a 5G system may include various network entities. For example, a 5G system includes an authentication server function (AUSF) entity (108), a core access and mobility management function (AMF) entity (103), a session management function (SMF) entity (105), a policy control function (PCF) entity (106), an application function (AF) entity (107), a unified data management (UDM) entity (109), a data network (DN) (110), a network exposure function (NEF) entity (111), a network slicing selection function (NSSF) entity (114), a network repository function (NRF) entity (115), a network data analytics function (NWDAF), and an edge application service domain repository: It may include an EDR), an edge application server (EAS), an EAS discovery function (EASDF), a user plane function (UPF) entity (104), a (radio) access network ((R)AN) (102), and a terminal, for example, a user device (UE) (101).

[0058] Each NF entity of the 5G system (100) supports the following functions.

[0059] AUSF (108) processes and stores data for the authentication of UE (101).

[0060] The AMF (103) provides functions for managing connectivity and mobility at the UE level, and can be connected to one AMF per UE by default. Specifically, the AMF (103) provides signaling between CN nodes for mobility between 3GPP access networks, termination of radio access network (RAN) CP interfaces (i.e., N2 interfaces), termination of NAS (non-access stratum) 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 execution of paging retransmission), mobility management control (subscription and policy), support for intra-system mobility and inter-system mobility, support for network slicing, SMF selection, lawful intercept (for AMF events and interfaces to LI systems), provision of session management (SM) message delivery between the UE and the SMF, transparent proxy for SM message routing, access authentication, access authorization including roaming authorization checks, and the UE and It supports functions such as providing SMS message delivery between SMSFs, security anchor function (SAF), and / or security context management (SCM). Some or all of the functions of an AMF entity (103) can be supported within a single instance of a single AMF entity.

[0061] DN (110) means, for example, operator services, internet access, or third-party services. DN (110) transmits a downlink protocol data unit (PDU) to a UPF entity (104) or receives a PDU transmitted from a UE (101) from a UPF entity (104).

[0062] The PCF entity (106) receives information about packet flow from the application server and provides the function of determining policies such as mobility management and session management. Specifically, the PCF entity (106) supports functions such as supporting a unified policy framework for controlling network behavior, providing policy rules so that control plane function entity(s) (e.g., AMF entity, SMF entity, etc.) can enforce policy rules, and implementing a front end to access related subscription information for policy decisions within the user data repository (UDR).

[0063] The SMF entity (105) provides session management functions, and if the UE (101) has multiple sessions, each session can be managed by a different SMF entity. Specifically, the SMF entity (105) performs functions such as session management (e.g., session establishment, modification, and termination, including maintaining a tunnel between the UPF entity (104) and the (R)AN (102) node), UE IP address allocation and management (optional authentication), selection and control of UP functions, setting up traffic steering to route traffic from the UPF entity (104) to an appropriate destination, termination of interfaces toward policy control functions, enforcement of policy and QoS (quality of service) control parts, lawful interception (for SM events and interfaces to LI systems), termination of the SM (session management) part of NAS messages, downlink data notification, initiator of AN (access network) specific SM information (transmitted to (R)AN (102) via N2 through the AMF entity (103)), determination of the session and service continuity (SSC) mode of the session, and roaming functions. Supports. Some or all of the functions of an SMF entity (105) can be supported within a single instance of an SMF entity.

[0064] The UDM entity (109) stores user subscription data, policy data, etc. The UDM entity (109) includes two parts: an application front end (FE) and a user data repository (UDR).

[0065] The front end (FE) includes a UDM FE responsible for location management, subscription management, and credential processing, and a PCF entity responsible for policy control. The UDR stores data required for the functions provided by the UDM-FE and policy profiles required by the PCF entity. The data stored in the UDR includes user subscription data, such as subscription identifiers, security credentials, access and mobility-related subscription data, and session-related subscription data, as well as policy data. The UDM-FE accesses subscription information stored in the UDR and supports functions such as authentication credential processing, user identification handling, access authentication, enrollment / mobility management, subscription management, and SMS management.

[0066] The UPF entity (104) transmits the downlink PDU received from the DN (110) to the UE (101) via the (R)AN (102), and transmits the uplink PDU received from the UE (101) to the DN (110) via the (R)AN (102). Specifically, the UPF entity (104) supports functions such as an anchor point for intra / inter RAT mobility, an external PDU session point for interconnection to a data network, packet routing and forwarding, packet inspection and policy rule enforcement in the user plane, lawful intercept, traffic usage reporting, an uplink classifier to support routing of traffic flows to a 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 verification (SDF mapping between service data flow (SDF) and QoS flow), transport level packet marking within the uplink and downlink, downlink packet buffering, and downlink data notification triggering. Some or all of the functions of a UPF entity (104) can be supported within a single instance of a UPF.

[0067] The AF entity (107) interacts with the 3GPP core network to provide services (e.g., support for application impact on traffic routing, access to network capability exposure, and interaction with policy frameworks for policy control).

[0068] (R)AN(102) is a general term for a new radio access network that supports both evolved E-UTRA, which is an evolved version of 4G radio access technology, and new radio access technology (new radio: NR) (e.g., gNB).

[0069] The gNB provides functions for radio resource management (i.e., radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to UEs on uplink / downlink (i.e., scheduling)), IP (Internet Protocol) header compression, encryption and integrity protection of user data streams, selection of an AMF upon UE attachment when routing to an AMF is not determined from information provided to the UE, routing of user plane data to UPF(s), routing of control plane information to an AMF, connection setup and termination, scheduling and transmission of paging messages (originating from the AMF), scheduling and transmission of system broadcast information (originating from the AMF or operation and maintenance: O&M), measurement and measurement reporting setup for mobility and scheduling, transport-level packet marking on the uplink, session management, support for network slicing, QoS flow management, and data It supports features such as mapping to a wireless bearer, support for UEs in inactive mode, distribution of NAS messages, NAS node selection, wireless access network sharing, dual connectivity, and tight interworking between NR and E-UTRA.

[0070] UE (user equipment, 101) refers to user equipment. User equipment may be referred to by terms such as terminal, ME (mobile equipment), MS (mobile station). Additionally, user equipment may be portable devices such as laptops, mobile phones, PDAs (personal digital assistants), smartphones, multimedia devices, etc., or non-portable devices such as PCs (personal computers) and vehicle-mounted devices.

[0071] NEF (111) provides a means to securely expose services and capabilities for third parties, internal exposure / re-exposure, application functions, and edge computing, provided by 3GPP network functions. NEF (111) receives information from other NF(s) (based on the exposed capability(s) of other NF(s). NEF (111) can store the received information as structured data using a standardized interface to a data storage network function. The stored information can be re-exposed to other NF entity(s) and AF entity(s) by the NEF entity (111) and used for other purposes such as analysis.

[0072] EASDF is an NF that can add an ECS (EDNS (extension mechanisms for DNS) client subnet) option, which can be expressed as the address of the DNS server to forward the terminal's DNS (domain name system) request for each FQDN (fully qualified domain name) and the IP subnet address that must be added when forwarding the terminal's DNS request. EASDF receives EAS (exchange active sync) domain configuration information from EDR and, according to the received information, performs processing for DNS request messages received from the terminal. Additionally, EASDF receives the terminal IP address, the terminal's location information within 3GPP, DNS message processing rules, and DNS message reporting rules from SMF (105), processes DNS Query messages received from the terminal and DNS response messages received from the DNS server, and, according to the DNS message reporting rules, performs the function of transmitting information within the DNS message and statistical information processed therefrom to SMF (105).

[0073] NRF (115) supports service discovery. It receives NF discovery requests from NF instances and provides information about discovered NF instances to the NF instances. It also maintains available NF instances and the services they support.

[0074] Meanwhile, FIG. 1a illustrates a reference model for the case where a UE (101) accesses a DN (110) using a single PDU session for convenience of explanation, but the present disclosure is not limited thereto.

[0075] The UE (101) can access two (i.e., local and central) data networks simultaneously using multiple PDU sessions. In this case, two SMFs may be selected for different PDU sessions. However, each SMF may have the ability to control both the local UPF and the central UPF within the PDU session.

[0076] Additionally, the UE (101) may simultaneously access two data networks (i.e., local and central) provided within a single PDU session.

[0077] In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. For example, the reference point(s) included in the 5G system (100) of FIG. 1 are as follows.

[0078] - N1: Reference point between UE (101) and AMF (103)

[0079] - N2: Reference point between (R)AN(102) and AMF(103)

[0080] - N3: Reference point between (R)AN(102) and UPF(104)

[0081] - N4: Reference point between SMF (105) and UPF (104)

[0082] - N5: Reference point between PCF (106) and AF (107)

[0083] - N6: Reference point between UPF (104) and DN (110)

[0084] - N7: Reference point between SMF (105) and PCF (106)

[0085] - N8: Reference point between UDM (109) and AMF (103)

[0086] - N10: Reference point between UDM (109) and SMF (105)

[0087] - N11: Reference point between AMF (103) and SMF (105)

[0088] - N12: Reference point between AMF (103) and AUSF (108)

[0089] - N13: Reference point between UDM (109) and AUSF (108)

[0090] - N14: Reference point between 2 AMFs (103)

[0091] - N15: Reference point between PCF and AMF in non-roaming scenarios, reference point between PCF and AMF within the visited network in roaming scenarios

[0092] - Nx: Reference point between SMF(105) and EASDF

[0093] - Ny: Reference point between NEF(EDF)(111) and EASDF

[0094] FIG. 1b is an example of an IMS-DC (IP (Internet Protocol) Multimedia Subsystem Data Channel) structure providing an IMS (IP (Internet Protocol) Multimedia Subsystem) service-based data channel service according to one embodiment of the present disclosure.

[0095] In the IMS-DC structure, the terminal can transmit a SIP (session initiation protocol) INVITE message to an existing CSCF (proxy-call session control function), such as a P-CSCF (proxy-call session control function) and a S-SCSF (serving-call session control function), to request a call session connection. The SIP INVITE message may include SDP (Session Description Protocol) information, and information regarding media-related parameters and multiplexing requirements may be included within the SDP information and transmitted to the network. Additionally, to utilize IMS data channel services, the terminal may include an SDP offer containing bootstrap information within the SIP INVITE message, along with an existing SDP offer for video or audio session connections, and transmit it.

[0096] The S-CSCF (serving-call session control function), upon receiving a SIP INVITE containing the above SDP information, can forward the contents of the bootstrap-related SDP offer to the IMS AS if the SIP INVITE includes a bootstrap data channel SDP offer for requesting a data channel service connection. At this time, the S-CSCF can check whether the terminal or network supports IMS-DC based on the contents of the received bootstrap-related SDP offer; if both parties support the data channel, it can decide to forward information for the bootstrap data channel connection to the IMS AS. The IMS AS, upon receiving the bootstrap-related SDP offer message from the S-CSCF, can first verify with the HSS (home subscriber server) whether the relevant UE or subscriber can use the data channel service. If it is determined based on the user profile that the user cannot use the data channel, the IMS AS can perform a multimedia telephony (MMTel) session setup operation without a data channel connection through the standard IMS process. In addition, if the user is unable to use data channel-based services, the IMS AS can update the SIP INVITE message by deleting the DC (data channel) related media information within the SIP INVITE message received from the S-CSCF, and then forward the updated SIP INVITE message to the S-CSCF.

[0097] If the service user can use a service based on the IMS data channel, data channel bootstrapping can be performed through a data channel call request to the DCSF (Data channel Signaling function). The IMS AS can select a DCSF by performing discovery and selection of a DCSF instance from the NRF based on the network operator's local configuration or information transmitted from the UE. The IMS AS can deliver a Session Event Control Notification (SessionEventControl_Notify) message containing information such as SessionEstablishmentRequestEvent, Session ID, CallingID, CalledID, SessionCase, Event initiator, MediaInfoList, and DC Stream ID to the DCSF selected through the above process.

[0098] Upon receiving a DC control request from the IMS AS, the DCSF can make policy decisions regarding how to create bootstrap data channels based on relevant parameters within the DC control request message. Additionally, the DCSF can determine MDC1 media information to enable the UE to download applications via the media function (MF) or multimedia resource function (MRF).

[0099] Based on the above decision information, the DCSF can send a MediaControl_MediaInstruction message containing information such as SessionID and MediaInstructionSet to the IMS AS. The DCSF can send the MDC1 media endpoint address, DC stream ID, and alternative information for the URL of the application list delivered from the MDC1 interface to the IMS AS by including them in the MediaInstructionSet. Based on this, the DCSF can provide the IMS AS with a policy regarding how to create bootstrap data channels using MF on the originating and terminating sides.

[0100] IMS AS can select an MF by using NRF to search for and select an MF instance or enhanced MRF that supports local settings or DC media functions.

[0101] The IMS AS can transmit a list of Media Termination Descriptors to the MF selected in the above process via the Nmf_MRM_Create message. The IMS AS may request the creation of two different Media Terminations. One Media Termination information may be information related to local bootstrap media, and the other Media Termination information may represent information related to remote bootstrap media to be provided to a remote UE. Each Media Termination information may include information regarding resource allocation requests for the Mb and MDC1 interfaces. The MF may transmit the negotiation result of the corresponding data channel media resource information to the IMS AS.

[0102] The IMS AS can deliver a response to a MediaInstruction request from the DCSF. The response message may include information regarding the result of the above operation and information related to the negotiation of MDC1 data channel media resource information.

[0103] DCSF can store media resource information within the response message to the MediaInstruction request received from the IMS AS and forward the response message related to the data channel connection notification (SessionEventControl_Notify) request from the IMS AS to the IMS AS.

[0104] IMS AS can send a SIP INVITE message to S-CSCF containing an updated SDP offer with media information added from an MF or enhanced MRF. S-CSCF can forward the received SIP INVITE message containing the updated SDP offer to the remote network and UE#2.

[0105] UE#2 and the terminating network may include the bootstrap data channel-related SDP response in an 18X response message and forward it to the originating network. Based on the received SDP response message, the MF or enhanced MRF may update UE#2's data channel media resource information. Subsequently, UE#2 and the terminating network may send a 200 OK response message indicating that the request has been successfully completed.

[0106] The IMS AS can notify the DCSF of event information regarding a successful session connection by forwarding a SessionEventControl Notify message containing SessionEstablishmentSuccessEvent, SessionID, and MediaInfoList. Subsequently, upon receiving a response message from the DCSF regarding the notification of the successful session connection event, the IMS AS can forward a 200 OK message to UE#1 indicating that the bootstrap data channel has been established. This enables the establishment of a bootstrap data channel between UE#1, UE#2, and the originating MF or enhanced MRF. Afterward, UE#1 and UE#2 can request data channel applications by forwarding application request messages to the MF or enhanced MRF. If multi-DC applications are supported, UE#1 and UE#2 can request an application list from the MF or enhanced MRF. The MF or MRF can change the root URL to the application-related URL information based on the replacement URL information received from the DCSF. Subsequently, the MF can forward the corresponding application request message received from the UE to the DCSF. The DCSF can provide an application list or appropriate data applications to UE#1 and UE#2 depending on the UE's data channel processing capability and selection. If a terminating MF or MRF is used depending on the location of the MF, the terminal can perform the above process through the terminating DCSF and download appropriate data channel applications.

[0107] After the IMS session and bootstrap data channel connections and data channel applications have been downloaded to UE#1 and UE#2, UE#1 may send a SIP reINVITE message containing an updated SDP to the IMS AS. The updated SDP may include not only bootstrap data channel information but also application data channel request information and related DC application binding information.

[0108] The IMS AS can determine whether to notify the DCSF of a media change request event based on user subscription data information. If the IMS AS decides to notify the DCSF of the event, it can send a SessionEventControl_Notify message to the DCSF that includes the MediaChangeRequest Event, Session ID, Event Direction, Event initiator, and Media Info List.

[0109] After receiving a session event notification message, the DCSF can determine a policy regarding how to execute an application data channel connection request based on the relevant parameters received through the notification message and the network operator's policy. If UE#2 is the target endpoint and an anchor for a local MF or enhanced MRF is not required, the DCSF may decide to add an application data channel media descriptor to the SDP offer. If an MF or enhanced MRF is required as an anchor for the application data channel, the DCSF may forward a Nimsas_MediaControl message to the IMS AS to instruct the IMS AS to perform the allocation of data channel media resources for the MF or enhanced MRF.

[0110] DCSF can forward a response to a session event notification message to IMS AS. Subsequently, IMS AS can forward a SIP reINVITE message to the originating S-CSCF, and S-CSCF can forward it to the terminating network and UE#2.

[0111] UE#2 and the terminating network can include a 200 OK response within the SDP response related to the application data channel and transmit it to the originating network. Subsequently, the IMS AS, upon receiving an SDP offer response message containing 200 OK from the terminating network, can notify the DCSF of information regarding the successful data channel change. The DCSF sends a response to the notification to the IMS AS, and the IMS AS can then transmit the 200 OK response to UE#1 via the originating S-CSCF and P-CSCF. At this time, the P-CSCF of the originating network can perform QoS procedures for the application data channel media based on the SDP response information containing the 200 OK response. UE#1 can transmit an ACK to the terminating network. Through the above process, the application data channel connection operation between UE#1 and UE#2 can be performed.

[0112] FIG. 2a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the IMS AS may determine whether to accept a P2P-based application data channel session connection request message requested by a terminal based on whether it supports a change of an Endpoint within the application data channel related information requested by the terminal, in order to support a DC interworking operation using a DC AS based on a P2P-based application data channel session connection request message requested by the terminal. In an embodiment of the present disclosure, FIG. 2a, if the IMS AS cannot support a change of an Endpoint within the application data channel related information, the IMS AS may transmit a rejection message regarding the application data channel session connection request message requested by the terminal to the terminal. The rejection message transmitted from the IMS AS to the terminal may include rejection-related information (e.g., cause). In one embodiment of the present disclosure, the IMS AS may transmit information to the originating side UE (UE #1) that a request for a P2A ADC session connection for DC interworking is needed or required within the rejection-related information (e.g., cause). UE #1, having received a rejection message for establishing a P2P-based application data channel session from the IMS AS that includes information that a request for a P2A ADC session connection for DC interworking is needed or required within the rejection-related information (e.g., cause), may generate and transmit a request message for establishing a P2A-based application data channel session to the network for a request for a data channel service using a DC application that supports DC interworking operations.

[0113] In Step 1, the DC AS can perform a request to subscribe to DC interworking events to the IMS AS. The event subscription request message may include information related to DC interworking, such as specific application information that supports the supported DC interworking (e.g., DC Interworking Information including DC interworking supported Application ID).

[0114] In Step 2, while using a voice or video call-based IMS service with UE #2, UE #1 may request a bootstrap data channel connection operation to download a DC application and receive application-related information for using an IMS DC service with UE #2. At this time, based on the bootstrap data channel connection response message information of UE #2, if UE #2 is a terminal that does not support the IMS data channel service (e.g., MTSI UE) or if UE #2 rejects the request for the IMS data channel service, the DCSF may perform a media resource creation or update operation within the MF considering only the Originating terminal (UE #1). Whether to perform the media resource creation or update operation within the MF considering only the Originating terminal (UE #1) can be determined by the DCSF based on the bootstrap data channel connection response message information of UE #2, according to the subscription information of the Originating terminal (UE #1) and / or the settings of the service provider. If the DCSF supports DC interworking operations based on the subscription information of the originating terminal (UE #1) and / or the service provider's settings, the DCSF can notify UE #1 via the IMS AS that the bootstrap data channel session requested by UE #1 has been successfully established. Subsequently, UE #1 can download data channel applications and data channel application-related information for using the IMS data channel service through the bootstrap data channel.

[0115] In Step 3, UE #1 can transmit a P2P type application data channel session connection request message (re-INVITE) to the network (P-CSCF, S-CSCF, IMS AS) based on the data channel application downloaded via the bootstrap data channel in Step 2. The application-related session technical protocol offer (SDP offer) within the application data channel session connection request message may include at least one piece of information, such as an adc-stream-id containing Endpoint information and an Application ID. In one embodiment of the present disclosure, UE #1 may include information set to "adc-stream-id-UE" within the application-related session technical protocol offer (SDP offer) for a P2P type application data channel session connection request. If it is a P2A type application data channel session connection request, information set to "adc-stream-id-server" may be included within the application-related session technical protocol offer (SDP offer).

[0116] In Step 4, the IMS AS can select a DCSF (local or remote) to forward the data channel session connection request based on the application-related session technical protocol offer (SDP offer) within the application data channel session connection request message received from UE #1. For example, if the stream-id in the application-related session technical protocol offer (SDP offer) is set to 0, the information for creating the application data channel can be forwarded to the DCSF of the Local Network (e.g., the Originating Network in the case of UE #1). If the stream-id in the application-related session technical protocol offer (SDP offer) is set to 100, the IMS AS can forward the data channel session connection request to the Terminating Network and request the Terminating DCSF to perform the action for creating the application data channel.

[0117] In Step 5, if the stream-id in the application data channel session connection request message received by the IMS AS from UE #1 in the above step is set to 0, the IMS AS may send a Session Event Control Notification (Nimsas_SessionEventControl_Notify) message to the Local (Originating) side DCSF. The Session Event Control Notification message may include at least one of the following: mediaChangeRequestEvent, Session ID, MediaInfoList, EventInitiator, and DC Interworking Information received by the IMS AS from the DC AS.

[0118] In Step 6, the DCSF can determine whether to perform DC interworking based on information for performing application data channel session setup operations received from the IMS AS (e.g., Application ID) and the response message received from UE #2 in Step 2 (port information in the Bootstrap DC-related SDP answer is 0). At this time, the DCSF can determine whether to perform DC interworking by receiving UE #1's subscription information from the HSS and additionally considering whether UE #1 can use the DC interworking service.

[0119] In step 6a, the DCSF may transmit information that DC interworking operation is required (DC Interworking Required or DC Interworking Required via DC AS) and UE #2 side information to the IMS AS via a Session Event Control Notify Response (Nimsas_SessionEventControl_Notify Response) message. The Session Event Control Notify Response (Nimsas_SessionEventControl_Notify Response) message transmitted from the DCSF to the IMS AS may additionally include information that a change based on the P2P application DC type is required (Endpoint change Required or changes P2P application DC to P2A application DC Required).

[0120] In steps 6b through 6e, the IMS AS may transmit to the NEF via the Nimsas_ImsEE_Notify Request message that a DC interworking operation has occurred in accordance with the DC interworking event subscription request received from the DC AS in step 1, and the NEF may transmit the event notification message received from the IMS AS to the DC AS via the Nnef_ImsEE_Notify Request. The notification message may include DC Interworking Required and UE #2 side information. The operations of steps 6b through 6e may be performed after step 7 according to operator policy or settings. Specifically, in step 7, the IMS AS may determine whether to perform the operations of steps 6b through 6e based on the Endpoint information within the application data channel connection request message received from UE #1 through step 4, the DC interworking information received from the DC AS in step 1, or the DC interworking related information received from the DCSF in step 6a, depending on whether to perform a separate Endpoint change operation and whether policy permission is allowed. According to one embodiment of the present disclosure, if the Endpoint information in the connection request message received from UE#1 in step 4 is inconsistent with the Endpoint information in the information received from step 1 or step 6a, and the IMS AS determines to change the Endpoint information in the connection request message received from UE#1 (e.g., UE → Server), but the IMS AS does not support Endpoint conversion, the IMS AS may determine to perform the operations of steps 6b to 6e after a P2A-based application data channel reconnection request is received from UE#1.The DC AS, having received information from the IMS AS that DC interworking operation is required (DC Interworking Required) and information from the UE #2 side through the operations of steps 6b to 6e above, recognizes that it must transmit P2A-based application data channel data connected to the UE #1 to the UE #2 side based on the information from the UE #2 side within the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to the UE #2 via a separate message (e.g., SMS).

[0121] In Step 7, the IMS AS may recognize that an application data channel connection supporting DC interworking using DC AS is required based on the information received from the DCSF in Step 6a (DC Interworking Required or DC Interworking Required via DC AS) and the information that a change based on the P2P application DC type is required (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC). Alternatively, information regarding the requirement for an application data channel connection supporting DC interworking using DC AS may be transmitted from the DCSF to the IMS AS specifically through which network entity the DC interworking is required (e.g., DC Interworking Required via DC AS or DC Interworking Required via MF) within the information that the DC interworking operation is required. Alternatively, if an event subscription operation is performed from the DC AS, the requirement to support DC interworking using DC AS may be received from a pre-configured setting or from the DC interworking information transmitted from the DC AS in Step 1.An IMS AS that recognizes the need to perform an application data channel connection operation supporting DC interworking using DC AS through DC interworking information transmitted from DC AS in step 1 above or information transmitted from DCSF in step 6a indicating that a change based on P2A application DC type from P2P application DC type is required (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC or DC Interworking Required via DC AS) can check the session technology protocol processing policy of the IMS AS before transmitting an application data channel connection or update request to DCSF based on an application data channel connection request message requested by the terminal.Specifically, if the Endpoint information of the application data channel-related session technology protocol in the application data channel connection request message requested from the terminal in Step 3 is set to the P2P connection type (UE), and the Session Event Control Notification Response (Nimsas_SessionEventControl_Notify Response) message received from the DCSF through Step 6a contains information indicating that a change based on the P2A application DC type is required from the P2P application DC type (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC or DC Interworking Required via DC AS), the IMS AS may decide to convert the Endpoint information of the data channel-related session technology protocol received from the terminal from the P2P connection type (UE) to the P2A connection type (Server). Additionally, the IMS AS may decide to change or convert the Endpoint information within the media info transmitted to the DCSF to P2P, P2A, A2P, or P2A2P based on the information within the Endpoint conversion request message received in Step 6a or the DC Interworking information received from the DC AS in Step 1, in relation to the Endpoint information of the session technology protocol related to the data channel received from the terminal. After deciding to convert the Endpoint information within the session technology protocol transmitted from the terminal, the IMS AS may check whether the IMS AS supports the conversion function of the Endpoint information of the session technology protocol and / or whether the operator's policy allows the Endpoint conversion.If the IMS AS does not allow or support the conversion of Endpoint information within the session technical protocol offer, the IMS AS may decide to reject the application data channel connection request of the P2P connection type requested by UE #1 in Step 3. According to one embodiment of the present disclosure, the determination of the Endpoint conversion operation by the IMS AS and the acceptance or rejection of the application data channel of the connection type requested by UE #1 may occur due to a constraint that the information within the session technical protocol offer in the application data channel request message and the information (e.g., Endpoint) within the session technical protocol response in the application data channel response message must be identical.

[0122] In step 8, the IMS AS may transmit a rejection message to UE #1 rejecting a request for a P2P connection type application data channel connection if the IMS AS supports the conversion of Endpoint information and / or if the operator's policy does not allow the conversion of Endpoint information within the session technology protocol in the IMS AS. The rejection message transmitted from the IMS AS to the terminal may include an Application DC-related SDP answer (port number in the corresponding stream in the answer for Application DC set to zero) in which ADC-related port information is set to 0, and / or rejection-related information (e.g., cause) including information that a P2A ADC session connection request for DC interworking using the DC AS is needed or required (e.g., P2A ADC initiation is needed / required for DC interworking via DC AS).

[0123] In step 9, the terminal of UE #1 receives rejection-related information (e.g., cause) including information that a P2A ADC session connection request is needed or required (e.g., P2A ADC initiation is needed / required for DC interworking via DC AS), and then notifies the user that a P2A connection type application data channel connection request is required for DC interworking using DC AS. Based on this information, the user may re-request a P2A-based application data channel connection, or, through terminal settings, notify the user and automatically transmit a message requesting a P2A-based application data channel connection re-request to the network.

[0124] FIG. 2b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. Specifically, FIG. 2b may be operations performed after the steps illustrated in FIG. 2a have been performed.

[0125] In Step 10, UE #1, having received a message rejecting the establishment of a P2P-based application data channel session, can generate and transmit to the network a P2A-based application data channel session establishment request message configured with "adc-stream-id-server" for an application data channel connection request using a DC application that supports DC interworking operations using a DC AS. The application data channel session establishment request message that supports DC interworking operations using the DC AS may include UE #2 side information. The UE #2 side information included in the application data channel session establishment request message that supports DC interworking operations using the DC AS may include at least one of IMPU, Called ID, MSISDN, and IMSI.

[0126] In Step 11, the IMS AS, having received a P2A-based application data channel session establishment request message from the terminal, may transmit a Session Event Control Notification (SessionEventControl_Notify) message to the DCSF containing information such as SessionEstablishmentRequestEvent, Session ID, Calling ID, Called ID, SessionCase, Event initiator, MediaInfoList, and DC Stream ID to configure the application data channel using the DC AS. The DCSF, having received a DC control request from the IMS AS, may perform policy decisions for the P2A-based application data channel based on the relevant parameters within the DC control request message. Additionally, the DCSF may request MF-side MDC2 media information from the MF for the UE to establish an application data channel session using the DC AS. The DCSF may transmit a MediaControl_MediaInstruction message to the IMS AS containing information such as MF-side MDC2 media resource request information, Session ID, and MediaInstructionSet. The DCSF may transmit MDC2 interface information received from the MF via the IMS AS to the DC AS. DC AS can allocate MDC2 interface information on the DC AS side for P2A-based application data channel session connection based on MDC2 interface information received from DCSF. Subsequently, DC AS can transmit MDC2 media endpoint information on the DC AS side to DCSF. Subsequently, DCSF can update MDC2 media endpoint information within MF by transmitting a request for an MF resource update operation to MF through IMS AS based on the MDC2 media endpoint information on the DC AS side received from DCAS.A DCSF that has completed the configuration for a P2A-based application data channel session connection can store media resource information within the response message to a MediaInstruction request received from the IMS AS and forward a response message related to a data channel connection notification (SessionEventControl_Notify) request from the IMS AS to the IMS AS.

[0127] In step 12, after the IMS AS recognizes that the application data channel connection request operation based on DC interworking is performed through step 6a, it may perform a session connection request message modification operation to remove the application-related session technology protocol offer (e.g., SDP offer for application DC & bootstrap DC) from the session connection request message transmitted to UE #2.

[0128] In steps 13 and 14, the IMS AS may forward a session connection request message containing an audio and / or video call related session technology protocol offer to the terminating side network and terminal.

[0129] In step 15, UE #2 and the terminating side network may forward a 200 OK response message containing an audio and / or video call session description protocol response (SDP answer for audio / video) to the originating side IMS AS. Upon receiving the response message containing the audio and / or video call session description protocol response (SDP answer for audio / video) from the terminating side network and UE #2, the IMS AS may forward a Nimsas_SessionEventControl_Notify message containing result information (mediaChangeSuccessEvent), such as that the media change request event has successfully concluded, to the DCSF.

[0130] In step 16, the IMS AS may generate a modified 200 OK response message that includes a bootstrap and application data channel related session technical protocol response (SDP answer for application DC / bootstrap DC) within a 200 OK response message containing an audio and / or video call related session technical protocol response (SDP answer for audio / video) received from UE #2 and the terminating side network.

[0131] In step 17, the IMS AS can forward the response message to the application data channel session connection request requested by UE #1 in step 10 to the P-CSCF.

[0132] The P-CSCF that receives the 200 OK message in Step 18 can perform DC QoS processing operations related to the application data channel session and then forward the 200 OK message to UE #1.

[0133] In step 19, UE #1 can activate the application data channel of the P2A connection type with DC AS through MF.

[0134] In step 20, the DC AS, having received information from the IMS AS that DC interworking operation is required (DC Interworking Required) and information from the UE #2 side through steps 6b to 6e described in FIG. 2a, recognizes that it must transmit P2A-based application data channel data connected to the UE #1 to the UE #2 side based on the information from the UE #2 side within the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to UE #2 via a separate message (e.g., SMS). UE #2 can receive information about the data channel application transmitted from UE #1 through the DC AS.

[0135] FIG. 3a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the IMS AS may determine whether to accept a P2P-based application data channel session connection request message requested by a terminal based on whether it supports a change of an Endpoint within the application data channel related information requested by the terminal, in order to support a DC interworking operation using a DC AS based on a P2P-based application data channel session connection request message requested by the terminal. In an embodiment of the present disclosure, FIG. 3b shows that if the IMS AS cannot support a change of an Endpoint within the application data channel related information, the IMS AS may transmit a rejection message regarding the application data channel session connection request message requested by the terminal to the terminal. The rejection message transmitted from the IMS AS to the terminal may include rejection-related information (e.g., cause). In one embodiment of the present disclosure, the IMS AS may transmit information to the originating side UE (UE #1) that a request for a P2A ADC session connection for DC interworking is needed or required within rejection-related information (e.g., cause). UE #1, having received a rejection message for establishing a P2P-based application data channel session from the IMS AS that includes information that a request for a P2A ADC session connection for DC interworking is needed or required within rejection-related information (e.g., cause), may generate and transmit a request message for establishing a P2A-based application data channel session to the network for a request for a data channel service using a DC application that supports DC interworking operations.

[0136] In steps 1a through 1e, the DC AS may perform a request to subscribe to DC interworking events to the IMS AS. The event subscription request message may include information related to DC interworking, such as specific application information that supports the supported DC interworking (e.g., DC Interworking Information including DC interworking supported Application ID).

[0137] In Step 2, while using a voice or video call-based IMS service with UE #2, UE #1 may request a bootstrap data channel connection operation to download a DC application and receive application-related information for using an IMS DC service with UE #2. At this time, based on the bootstrap data channel connection response message information of UE #2, if UE #2 is a terminal that does not support the IMS data channel service (e.g., MTSI UE) or if UE #2 rejects the request for the IMS data channel service, the DCSF may perform a media resource creation or update operation within the MF considering only the Originating terminal (UE #1). Whether to perform the media resource creation or update operation within the MF considering only the Originating terminal (UE #1) can be determined by the DCSF based on the bootstrap data channel connection response message information of UE #2, according to the subscription information of the Originating terminal (UE #1) and / or the settings of the service provider. If the DCSF supports DC interworking operations based on the subscription information of the originating terminal (UE #1) and / or the service provider's settings, the DCSF can notify UE #1 via the IMS AS that the bootstrap data channel session requested by UE #1 has been successfully established. Subsequently, UE #1 can download data channel applications and data channel application-related information for using the IMS data channel service through the bootstrap data channel.

[0138] In Step 3, UE #1 can transmit a P2P type application data channel session connection request message (re-INVITE) to the network (P-CSCF, S-CSCF, IMS AS) based on the data channel application downloaded via the bootstrap data channel in Step 2. The application-related session technical protocol offer (SDP offer) within the application data channel session connection request message may include at least one piece of information, such as an adc-stream-id containing Endpoint information and an Application ID. In one embodiment of the present disclosure, UE #1 may include information set to "adc-stream-id-UE" within the application-related session technical protocol offer (SDP offer) for a P2P type application data channel session connection request. If it is a P2A type application data channel session connection request, information set to "adc-stream-id-server" may be included within the application-related session technical protocol offer (SDP offer).

[0139] In Step 4, the IMS AS can select a DCSF (local or remote) to forward the data channel session connection request based on the application-related session technical protocol offer (SDP offer) within the application data channel session connection request message received from UE #1. For example, if the stream-id in the application-related session technical protocol offer (SDP offer) is set to 0, the information for creating the application data channel can be forwarded to the DCSF of the Local Network (e.g., the Originating Network in the case of UE #1). If the stream-id in the application-related session technical protocol offer (SDP offer) is set to 100, the IMS AS can forward the data channel session connection request to the Terminating Network and request the Terminating DCSF to perform the action for creating the application data channel.

[0140] In Step 5, the IMS AS can determine whether to perform DC interworking based on information for performing application data channel session setup operations received from UE #1 (e.g., Application ID) and the response message received from UE #2 in Step 2 (port information in the Bootstrap DC-related SDP answer is 0). At this time, the IMS AS can determine whether to perform DC interworking by receiving UE #1's subscription information from the HSS and additionally considering whether UE #1 can use the DC interworking service.

[0141] In steps 6a through 6d, the IMS AS may transmit to the NEF via the Nimsas_ImsEE_Notify Request message that a DC interworking operation has occurred in accordance with the DC interworking event subscription request received from the DC AS in step 1, and the NEF may transmit the event notification message received from the IMS AS to the DC AS via the Nnef_ImsEE_Notify Request. The notification message may include DC Interworking Required and UE #2 side information. According to one embodiment of the present disclosure, after the IMS AS determines to convert or change Endpoint information within the session technical protocol transmitted from the terminal in accordance with the policy of the network operator or service provider, and checks the IMS AS's session technical protocol processing policy regarding the conversion of Endpoint information, if the IMS AS does not support or allow the change of Endpoint information within the session technical protocol transmitted from the terminal, the IMS AS may reject the corresponding application data channel connection request message received from the terminal. If the application data channel connection request message is rejected as described above, the IMS AS may perform steps 6a through 6d after receiving an application data channel reconnection request message from the terminal (UE #1) that includes modified Endpoint information within the session description protocol to support DC interworking.

[0142] In Step 7, the IMS AS can recognize that an application data channel connection supporting DC interworking using the DC AS is required based on the information (DC interworking information) received from the DC AS in Step 1. Information regarding the requirement for an application data channel connection supporting DC interworking using the DC AS can be received from the DC AS through pre-configuration or DC interworking information transmitted from the DC AS, indicating that DC interworking using the DC AS must be supported when an event subscription operation is performed from the DC AS. The IMS AS can recognize the execution of an application data channel connection operation supporting DC interworking using the DC AS based on the information received from the DC AS through Step 1. Specifically, the IMS AS can determine whether a conversion of the Endpoint information within the application data channel connection request message is necessary and decide on the Endpoint conversion based on the application ID and Endpoint information within the application data channel connection request message transmitted by UE #1 through Step 3 and the DC interworking information received through Step 1 (e.g., Application ID, DC Interworking required via DC AS, etc.). Through the above operation, if Endpoint conversion within mediainfo transmitted from IMS AS to DCSF is required, IMS AS can check the IMS AS session technology protocol processing policy related to Endpoint information conversion before transmitting the corresponding application data channel connection request to DCSF.Specifically, based on the IMS AS's session technology protocol processing policy, the IMS AS can check whether it supports converting the Endpoint information within an application data channel connection request message requested as a P2P connection type to a P2A connection type, and / or whether the operator's policy allows the conversion of Endpoint information. If the IMS AS determines the conversion of Endpoint information within the session technology protocol offer through the above operation, but the IMS AS does not support the Endpoint conversion function or does not allow the conversion due to the IMS AS's session technology protocol processing policy, such as an operator's policy, the IMS AS may decide to reject the application data channel connection request of the P2P connection type requested by UE #1 and then transmit the relevant information to UE #1. The determination of the Endpoint conversion operation by the IMS AS and the acceptance or rejection of the application data channel of the connection type requested by UE #1 may occur due to the constraint that the information within the session technology protocol offer in the application data channel request message and the information (e.g., Endpoint) within the session technology protocol response in the application data channel response message must be identical.

[0143] In Step 8, the IMS AS may transmit a rejection message to UE #1 rejecting a request for a P2P connection type application data channel connection, provided that the IMS AS in Step 7 determined the conversion of Endpoint information based on the information transmitted in Step 3 and Step 1 or Step 6a, but the IMS AS does not support the corresponding Endpoint conversion function and / or the operator's policy does not allow the conversion of Endpoint information within the session technology protocol in the IMS AS. The rejection message may include rejection-related information (e.g., cause) including information that a P2A ADC session connection request for DC interworking using the DC AS is needed or required (e.g., P2A ADC initiation is needed / required for DC interworking via DC AS). Upon receiving rejection-related information (e.g., cause) containing information that a P2A ADC session connection request is needed or required (e.g., P2A ADC initiation is needed / required for DC interworking via DC AS), the terminal of UE #1 can notify the user that a P2A connection type application data channel connection request is required for DC interworking using DC AS. Based on this information, the user may re-request a P2A-based application data channel connection, or, through terminal settings, notify the user and automatically transmit a message requesting a P2A-based application data channel connection re-request to the network.

[0144] In Step 9, UE #1, having received a message rejecting the establishment of a P2P-based application data channel session, can generate and transmit to the network a P2A-based application data channel session establishment request message configured with "adc-stream-id-server" for an application data channel connection request using a DC application that supports DC interworking operations using a DC AS. The application data channel session establishment request message that supports DC interworking operations using the DC AS may include UE #2 side information. The UE #2 side information included in the application data channel session establishment request message that supports DC interworking operations using the DC AS may include at least one of IMPU, Called ID, MSISDN, and IMSI.

[0145] FIG. 3b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. Specifically, FIG. 3b may be operations performed after the steps illustrated in FIG. 3a have been performed.

[0146] In step 10, the IMS AS, having received a P2A-based application data channel session establishment request message from the terminal, may transmit a Session Event Control Notification (SessionEventControl_Notify) message to the DCSF containing information such as SessionEstablishmentRequestEvent, Session ID, CallingID, CalledID, SessionCase, Event initiator, MediaInfoList, and DC Stream ID to configure the application data channel using the DC AS. The DCSF, having received a DC control request from the IMS AS, may perform policy decisions for the P2A-based application data channel based on the relevant parameters within the DC control request message. Additionally, the DCSF may request MF-side MDC2 media information from the MF for the UE to establish an application data channel session using the DC AS. The DCSF may transmit a MediaControl_MediaInstruction message to the IMS AS containing information such as MF-side MDC2 media resource request information, SessionID, and MediaInstructionSet. The DCSF may transmit MDC2 interface information received from the MF via the IMS AS to the DC AS. DC AS can allocate MDC2 interface information on the DC AS side for P2A-based application data channel session connection based on MDC2 interface information received from DCSF. Subsequently, DC AS can transmit MDC2 media endpoint information on the DC AS side to DCSF. Subsequently, DCSF can update MDC2 media endpoint information within MF by transmitting a request for an MF resource update operation to MF through IMS AS based on the MDC2 media endpoint information on the DC AS side received from DCAS.A DCSF that has completed the setup for a P2A-based application data channel session connection can store media resource information within the response message to the MediaInstruction request received from the IMS AS and transmit a response message related to the data channel connection notification (SessionEventControl_Notify) request from the IMS AS to the IMS AS. A DC AS that has received information from the IMS AS indicating that DC interworking operation is required (DC Interworking Required) and UE #2 side information through the operations of steps 6a to 6d above can recognize that it needs to transmit P2A-based application data channel data connected to UE #1 to UE #2 based on the UE #2 side information within the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to UE #2 via a separate message (e.g., SMS).

[0147] In step 11, after the IMS AS recognizes that the above step 5 is an application data channel connection request operation based on DC interworking, it can perform a session connection request message modification operation to remove the application-related session technology protocol offer (e.g., SDP offer for application DC & bootstrap DC) from the session connection request message transmitted to UE #2.

[0148] In steps 12 and 13, the IMS AS may forward a session connection request message containing an audio and / or video call related session technology protocol offer to the terminating side network and terminal.

[0149] In step 14, UE #2 and the terminating side network may forward a 200 OK response message containing an audio and / or video call session description protocol response (SDP answer for audio / video) to the originating side IMS AS. Upon receiving the response message containing the audio and / or video call session description protocol response (SDP answer for audio / video) from the terminating side network and UE #2, the IMS AS may forward a Nimsas_SessionEventControl_Notify message containing result information (mediaChangeSuccessEvent), etc., that the media change request event has successfully concluded to the DCSF.

[0150] In step 15, the IMS AS may generate a modified 200 OK response message by adding a bootstrap and application data channel related session technical protocol response (SDP answer for application DC / bootstrap DC) within a 200 OK response message containing an audio and / or video call related session technical protocol response (SDP answer for audio / video) received from UE #2 and the terminating side network.

[0151] In step 16, the IMS AS can forward the response message to the application data channel session connection request requested by UE #1 in step 10 to the P-CSCF.

[0152] The P-CSCF that receives the 200 OK message in Step 17 can perform DC QoS processing operations related to the application data channel session and then forward the 200 OK message to UE #1.

[0153] In step 18, UE #1 can activate the application data channel of the P2A connection type with DC AS through MF.

[0154] In step 19, the DC AS, having received information from the IMS AS that DC interworking operation is required (DC Interworking Required) and information from the UE #2 side through steps 6a to 6d described in FIG. 3a, recognizes that it must transmit P2A-based application data channel data connected to UE #1 to the UE #2 side based on the information from the UE #2 side within the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to UE #2 via a separate message (e.g., SMS). UE #2 can receive information about the data channel application transmitted from UE #1 through the DC AS.

[0155] FIG. 4a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the IMS AS may determine whether to accept a P2P-based application data channel session connection request message requested by a terminal based on whether it supports a change of an Endpoint within the application data channel related information requested by the terminal, in order to support a DC interworking operation using a DC AS based on a P2P-based application data channel session connection request message requested by the terminal. In an embodiment of the present disclosure, FIG. 4 shows that if the IMS AS cannot support a change of an Endpoint within the application data channel related information, the IMS AS may transmit a rejection message regarding the application data channel session connection request message requested by the terminal to the terminal. The rejection message transmitted from the IMS AS to the terminal may include rejection-related information (e.g., cause). In one embodiment of the present disclosure, the IMS AS may transmit information (e.g., cause) that a P2A ADC session connection for DC interworking is required to the Originating side UE (UE #1). The DC AS, having received an event notification message from the IMS AS containing information (e.g., DC Interworking Required) and UE #2 side information, may transmit a P2A connection type-based application data channel connection request to the IMS AS. The P2A connection type-based application data channel connection request information may include UE #2 side information.IMS AS can generate a P2A-based application data channel session establishment request message and transmit it to UE #1 for a request for a data channel service using a DC application that supports IMS DC interworking operation.

[0156] In Step 1, the DC AS can perform a request to subscribe to DC interworking events to the IMS AS. The event subscription request message may include information related to DC interworking, such as specific application information that supports the supported DC interworking (e.g., DC Interworking Information including DC interworking supported Application ID).

[0157] In Step 2, while using a voice or video call-based IMS service with UE #2, UE #1 may request a bootstrap data channel connection operation to download a DC application and receive application-related information for using an IMS DC service with UE #2. At this time, based on the bootstrap data channel connection response message information of UE #2, if UE #2 is a terminal that does not support the IMS data channel service (e.g., MTSI UE) or if UE #2 rejects the request for the IMS data channel service, the DCSF may perform a media resource creation or update operation within the MF considering only the Originating terminal (UE #1). Whether to perform the media resource creation or update operation within the MF considering only the Originating terminal (UE #1) can be determined by the DCSF based on the bootstrap data channel connection response message information of UE #2, according to the subscription information of the Originating terminal (UE #1) and / or the settings of the service provider. If the DCSF supports DC interworking operations based on the subscription information of the originating terminal (UE #1) and / or the service provider's settings, the DCSF can notify UE #1 via the IMS AS that the bootstrap data channel session requested by UE #1 has been successfully established. Subsequently, UE #1 can download data channel applications and data channel application-related information for using the IMS data channel service through the bootstrap data channel.

[0158] In Step 3, UE #1 can transmit a P2P type application data channel session connection request message (re-INVITE) to the network (P-CSCF, S-CSCF, IMS AS) based on the data channel application downloaded via the bootstrap data channel in Step 2. The application-related session technical protocol offer (SDP offer) within the application data channel session connection request message may include at least one piece of information, such as an adc-stream-id containing Endpoint information and an Application ID. In one embodiment of the present disclosure, UE #1 may include information set to "adc-stream-id-UE" within the application-related session technical protocol offer (SDP offer) for a P2P type application data channel session connection request. If it is a P2A type application data channel session connection request, information set to "adc-stream-id-server" may be included within the application-related session technical protocol offer (SDP offer).

[0159] In Step 4, the IMS AS can select a DCSF (local or remote) to forward the data channel session connection request based on the application-related session technical protocol offer (SDP offer) within the application data channel session connection request message received from UE #1. For example, if the stream-id in the application-related session technical protocol offer (SDP offer) is set to 0, the information for creating the application data channel can be forwarded to the DCSF of the Local Network (e.g., the Originating Network in the case of UE #1). If the stream-id in the application-related session technical protocol offer (SDP offer) is set to 100, the IMS AS can forward the data channel session connection request to the Terminating Network and request the Terminating DCSF to perform the action for creating the application data channel.

[0160] In Step 5, if the stream-id in the application data channel session connection request message received by the IMS AS from UE #1 in the above step is set to 0, the IMS AS may send a Session Event Control Notification (Nimsas_SessionEventControl_Notify) message to the Local (Originating) side DCSF. The Session Event Control Notification message may include at least one of the following: mediaChangeRequestEvent, Session ID, MediaInfoList, EventInitiator, and DC Interworking Information received by the IMS AS from the DC AS.

[0161] In Step 6, the DCSF can determine whether to perform DC interworking based on information for performing application data channel session setup operations received from the IMS AS (e.g., Application ID) and the response message received from UE #2 in Step 2 (port information in the Bootstrap DC-related SDP answer is 0). At this time, the DCSF can determine whether to perform DC interworking by receiving UE #1's subscription information from the HSS and additionally considering whether UE #1 can use the DC interworking service. According to one embodiment of the present disclosure, the DCSF can determine, based on the DC interworking information transmitted from the DC AS through the IMS AS via Step 1, that if the DC interworking operation of the application is DC interworking using the DC AS, the Endpoint information should be set to P2A (Server). The DCSF can determine whether a change or conversion (UE → Server) of the Endpoint information within mediainfo is necessary by comparing the DC interworking information received from the above DC AS and the information transmitted from the terminal to the IMS AS with the Endpoint information (UE, P2P ADC) of the Session Event Control Notification (Nimsas_SessionEventControl_Notify) message generated based on these factors, and decide to perform the conversion.

[0162] In step 6a, the DCSF may transmit information that DC interworking operation is required (DC Interworking Required) and UE #2 side information to the IMS AS via a session event control notification response (Nimsas_SessionEventControl_Notify Response) message. The session event control notification response (Nimsas_SessionEventControl_Notify Response) message transmitted from the DCSF to the IMS AS may additionally include information that a change based on the P2P application DC type from the P2P application DC type is required (Endpoint change Required or changes P2P application DC to P2A application DC Required).

[0163] In Step 7, the IMS AS may recognize that an application data channel connection supporting DC interworking using DC AS is required based on the information received from the DCSF in Step 6a (DC Interworking Required or DC Interworking Required via DC AS) and / or the information that changes based on the P2P application DC type are required (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC). The information regarding the requirement for an application data channel connection supporting DC interworking using DC AS may be conveyed from the DCSF in the specific network entity through which DC interworking is required (e.g., DC Interworking Required via DC AS or DC Interworking Required via MF) within the information that DC interworking operation is required. Alternatively, the IMS AS may receive the information that DC interworking using DC AS must be supported when an event subscription operation is performed from the DC AS, either through a pre-configured setting or through the DC interworking information (DC interworking information) conveyed from the DC AS in Step 1.An IMS AS that recognizes the need to perform an application data channel connection operation supporting DC interworking using DC AS through DC interworking information transmitted from DC AS in Step 1 above or information transmitted from DCSF in Step 6a indicating that a change based on the P2A application DC type from the P2P application DC type is required (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC or DC Interworking Required via DC AS) can check the session technology protocol processing policy of the IMS AS before transmitting an application data channel connection or update request to DCSF based on an application data channel connection request message requested by the terminal. Specifically, when the Endpoint information of the application data channel-related session technical protocol within the application data channel connection request message requested by the terminal is set to the P2P connection type (UE), the IMS AS determines whether to convert the Endpoint information of the said data channel-related session technical protocol to the P2A connection type (Server), and checks whether the IMS AS supports the Endpoint information conversion function and / or whether the operator's policy allows the Endpoint conversion. If the IMS AS determines to convert the Endpoint information within the session technical protocol offer but does not allow or support the Endpoint conversion according to the IMS AS's session technical protocol processing policy, it may decide to reject the application data channel connection request of the P2P connection type requested by UE #1.According to one embodiment of the present disclosure, the determination of an Endpoint conversion operation in an IMS AS and the acceptance or rejection of an application data channel of a connection type requested by UE #1 may occur due to a constraint that the information within the session technical protocol offer in the application data channel request message and the information within the session technical protocol response in the application data channel response message (e.g., Endpoint) must be identical.

[0164] In steps 8a through 8d, the IMS AS may transmit to the NEF via the Nimsas_ImsEE_Notify Request message that a DC interworking operation has occurred in accordance with the DC interworking event subscription request received from the DC AS in step 1, and the NEF may transmit the event notification message received from the IMS AS to the DC AS via the Nnef_ImsEE_Notify Request. The notification message may include DC Interworking Required and UE #2 side information and / or information that a change based on the P2A application DC type is required from the P2P application DC type transmitted from the DCSF (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC or DC Interworking Required via DC AS). The UE #2 side information included in the application data channel session establishment request message supporting the DC interworking operation using the DC AS may include at least one of IMPU, Called ID, MSISDN, and IMSI.

[0165] In step 9a, the IMS AS may transmit a rejection message to UE #1 rejecting a request for a P2P connection type application data channel connection if the IMS AS supports the conversion of Endpoint information and / or if the operator's policy does not allow the conversion of Endpoint information within the session technology protocol in the IMS AS. The rejection message may also transmit information to the Originating UE (UE #1) that a P2A ADC session connection for DC interworking using the DC AS is required (P2A ADC required for DC interworking).

[0166] In step 9b, the terminal of UE #1 may notify the user that it plans to reconnect to the P2A ADC session connection.

[0167] FIG. 4b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. Specifically, FIG. 4b may be operations performed after the steps illustrated in FIG. 4a have been performed.

[0168] In step 10, the DC AS, having received an event notification message containing information that DC interworking is required from the IMS AS (DC Interworking Required) and UE #2 side information and / or information that changes based on the P2A application DC type are required from the P2P application DC type transmitted from the DCSF (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC or DC Interworking Required via DC AS) through steps 8a to 8d described in FIG. 4a, may transmit information requesting the execution of an application data channel connection request based on the P2A connection type (reINVITE required for P2A ADC set up) to the IMS AS. The application data channel connection request information based on the P2A connection type may include UE #2 side information.

[0169] In Step 11, the IMS AS, having received an application data channel connection request based on the P2A connection type from the DC AS, can generate a P2A-based application data channel session establishment request message and forward it to UE #1. Specifically, the IMS AS can generate a P2A-based application data channel session establishment request message configured with "adc-stream-id-server" for an application data channel connection request using a DC application that supports DC interworking operations using the DC AS, and forward it to UE #1.

[0170] In step 12, UE #1, having received a request message from IMS AS to establish a P2A-based application data channel session, can send an application data channel session description protocol response (SDP answer for application DC) containing information on whether to accept the P2A-based application data channel to IMS AS via message 183.

[0171] In Step 13, the IMS AS may transmit a SessionEventControl_Notify message to the DCSF containing information such as SessionEstablishmentRequestEvent, Session ID, CallingID, CalledID, SessionCase, Event initiator, MediaInfoList, and DC Stream ID to configure an application data channel using the DC AS. Upon receiving a DC control request from the IMS AS, the DCSF may make policy decisions for the P2A-based application data channel based on the relevant parameters within the DC control request message. Additionally, the DCSF may request MF-side MDC2 media information from the MF for the UE to establish an application data channel session using the DC AS. The DCSF may transmit a MediaControl_MediaInstruction message to the IMS AS containing information such as MF-side MDC2 media resource request information, SessionID, and MediaInstructionSet. The DCSF may transmit the MDC2 interface information received from the MF via the IMS AS to the DC AS. DC AS can allocate MDC2 interface information on the DC AS side for P2A-based application data channel session connection based on MDC2 interface information received from DCSF. Subsequently, DC AS can transmit MDC2 media endpoint information on the DC AS side to DCSF. Subsequently, DCSF can update MDC2 media endpoint information within MF by transmitting a request for an MF resource update operation to MF through IMS AS based on the MDC2 media endpoint information on the DC AS side received from DCAS.A DCSF that has completed the configuration for a P2A-based application data channel session connection can store media resource information within the response message to a MediaInstruction request received from the IMS AS and forward a response message related to a data channel connection notification (SessionEventControl_Notify) request from the IMS AS to the IMS AS.

[0172] In step 14, the IMS AS can perform a session connection request message modification operation by removing application-related session technology protocol offers (e.g., SDP offer for application DC & bootstrap DC) from the session connection request message transmitted to UE #2 after recognizing that the request is for a DC interworking-based application data channel connection operation through step 6a or step 7 described in FIG. 4a.

[0173] In steps 15 and 16, the IMS AS may forward a session connection request message containing an audio and / or video call related session technology protocol offer to the terminating side network and terminal.

[0174] In step 17, UE #2 and the terminating side network may forward a 200 OK response message containing an audio and / or video call session description protocol response (SDP answer for audio / video) to the originating side IMS AS. Upon receiving the response message containing the audio and / or video call session description protocol response (SDP answer for audio / video) from the terminating side network and UE #2, the IMS AS may forward a Nimsas_SessionEventControl_Notify message to the DCSF containing result information (mediaChangeSuccessEvent), such as that the media change request event has successfully concluded.

[0175] In step 18, IMS AS can convey to UE #1 via a PRACK message that the P2A-based application data channel setup has been successfully performed.

[0176] In step 19, UE #1 can forward a 200 OK response message to the P-CSCF containing a P2A-based application data channel related session description protocol response (SDP answer for application DC / bootstrap DC) received from the IMS AS.

[0177] After receiving a 200 OK message from UE #1 in steps 20 and 21, the P-CSCF can perform DC QoS processing operations related to the application data channel session and then forward the 200 OK message to the IMS AS.

[0178] UE #1, having received an ACK for a response message regarding a P2A-based application session connection from IMS AS in steps 22 and 23, can activate an application data channel of the P2A connection type with DC AS through MF.

[0179] In step 24, the DC AS, having received information from the IMS AS that DC interworking operation is required (DC Interworking Required) and information from UE #2 through steps 8a to 8d described in FIG. 4a, recognizes that it must transmit P2A-based application data channel data connected to UE #1 to UE #2 based on the information from UE #2 in the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to UE #2 via a separate message (e.g., SMS). UE #2 can receive information about the data channel application transmitted from UE #1 through the DC AS.

[0180] FIG. 5a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the IMS AS can determine whether to accept a P2P-based application data channel session connection request message requested by a terminal based on whether it supports changing an Endpoint within the application data channel related information requested by the terminal, in order to support a DC interworking operation using a DC AS based on a P2P-based application data channel session connection request message requested by the terminal. If the IMS AS supports changing an Endpoint within the application data channel related information, the IMS AS can perform an application data channel configuration operation of a P2A connection type based on the changed Endpoint information, change the Endpoint information within the response message transmitted to UE #1 to the Endpoint information originally requested by the terminal, and then transmit a response message for the updated application data channel session connection request to UE #1.

[0181] In steps 1a through 1e, the DC AS may perform a request to subscribe to DC interworking events to the IMS AS. The event subscription request message may include information related to DC interworking, such as specific application information that supports the supported DC interworking (e.g., DC Interworking Information including DC interworking supported Application ID).

[0182] In Step 2, while using a voice or video call-based IMS service with UE #2, UE #1 may request a bootstrap data channel connection operation to download a DC application and receive application-related information for using an IMS DC service with UE #2. At this time, based on the bootstrap data channel connection response message information of UE #2, if UE #2 is a terminal that does not support the IMS data channel service (e.g., MTSI UE) or if UE #2 rejects the request for the IMS data channel service, the DCSF may perform a media resource creation or update operation within the MF considering only the Originating terminal (UE #1). Whether to perform the media resource creation or update operation within the MF considering only the Originating terminal (UE #1) can be determined by the DCSF based on the bootstrap data channel connection response message information of UE #2, according to the subscription information of the Originating terminal (UE #1) and / or the settings of the service provider. If the DCSF supports DC interworking operations based on the subscription information of the originating terminal (UE #1) and / or the service provider's settings, the DCSF can notify UE #1 via the IMS AS that the bootstrap data channel session requested by UE #1 has been successfully established. Subsequently, UE #1 can download data channel applications and data channel application-related information for using the IMS data channel service through the bootstrap data channel.

[0183] In Step 3, UE #1 can transmit a P2P type application data channel session connection request message (re-INVITE) to the network (P-CSCF, S-CSCF, IMS AS) based on the data channel application downloaded through the bootstrap data channel in Step 2. The application-related session technical protocol offer (SDP offer) within the application data channel session connection request message may include at least one piece of information, such as an adc-stream-id and an Application ID, which include Endpoint information. In one embodiment of the present disclosure, UE #1 may include information set to "adc-stream-id-UE" within the application-related session technical protocol offer (SDP offer) for a P2P type application data channel session connection request.

[0184] In Step 4, the IMS AS can select a DCSF (local or remote) to forward the data channel session connection request based on the application-related session technical protocol offer (SDP offer) within the application data channel session connection request message received from UE #1. For example, if the stream-id in the application-related session technical protocol offer (SDP offer) is set to 0, the information for creating the application data channel can be forwarded to the DCSF of the Local Network (e.g., the Originating Network in the case of UE #1). If the stream-id in the application-related session technical protocol offer (SDP offer) is set to 100, the IMS AS can forward the data channel session connection request to the Terminating Network and request the Terminating DCSF to perform the action for creating the application data channel.

[0185] In Step 5, the IMS AS can determine whether to perform DC interworking based on information for performing an application data channel session setup operation received from UE #1 (e.g., Application ID) and the response message received from UE #2 in Step 2 (port information in the Bootstrap DC-related SDP answer is 0). At this time, the IMS AS can determine whether to perform DC interworking by receiving UE #1's subscription information from the HSS and additionally considering whether UE #1 can use the DC interworking service. According to one embodiment of the present disclosure, the IMS AS can determine that the data channel application requested by the terminal is a DC AS-based DC interworking-based service by using the application ID and Endpoint information in the application data channel connection request message received from the terminal through Step 4 and the information received from the DC AS through Step 1 (e.g., application ID and DC interworking information).

[0186] According to one embodiment of the present disclosure, the Endpoint information within the application data channel connection request message received by the IMS AS from the terminal via step 4 and the Endpoint information within the application data channel configuration information for supporting DC AS-based DC interworking-based services received from the DC AS via step 1 may be different. After determining whether to convert or change the Endpoint information within the session technology protocol transmitted from the terminal, the IMS AS may check whether the IMS AS supports changing the Endpoint information based on network operator policies or the support of the Endpoint conversion function within the IMS AS. If the IMS AS supports changing the Endpoint information, the IMS AS may convert or change the Endpoint information within the corresponding application data channel connection request message received from the terminal. Through the above operation, the IMS AS may convert the Endpoint within the mediainfo transmitted to the DCSF from UE to Server.

[0187] In steps 6a through 6d, the IMS AS may transmit to the NEF via the Nimsas_ImsEE_Notify Request message that a DC interworking operation has occurred in accordance with the DC interworking event subscription request received from the DC AS in step 1, and the NEF may transmit the event notification message received from the IMS AS to the DC AS via the Nnef_ImsEE_Notify Request. The notification message may include DC Interworking Required and UE #2 side information. The UE #2 side information may include at least one of IMPU, Called ID, MSISDN, and IMSI. According to one embodiment of the present disclosure, the IMS AS may decide to perform the operations from steps 6a through 6d after step 7, in which it is determined that although the Endpoint information in the connection request message received from UE #1 in step 3 is inconsistent with the Endpoint information in the DC interworking information received from step 1, the IMS AS is allowed to convert the Endpoint.

[0188] In Step 7a, the IMS AS may recognize that an application data channel connection supporting DC interworking using the DC AS is required, based on the information received from UE #2 during the bootstrap data channel session connection operation and the DC interworking information received from the DC AS via Step 1. Information regarding the requirement for an application data channel connection supporting DC interworking using the DC AS may be received from the DC interworking information transmitted from the DC AS via Step 1, or from the pre-configuration indicating that DC interworking using the DC AS must be supported when an event subscription operation is performed from the DC AS. Having recognized the execution of an application data channel connection operation supporting DC interworking using the DC AS through the above information and operations, the IMS AS may check the session technology protocol processing policy of the IMS AS before transmitting the application data channel connection request to the DCSF. Specifically, after the IMS AS determines to convert the Endpoint information within the application data channel connection request message requested as a P2P connection type in Step 3 to a P2A connection type, it can check whether the IMS AS supports the Endpoint conversion function and / or whether the operator's policy allows the Endpoint conversion. The determination of the Endpoint conversion operation by the IMS AS and the acceptance or rejection of the application data channel of the connection type requested by UE #1 may occur due to a constraint that the information within the session technical protocol offer in the application data channel request message and the information (e.g., Endpoint) within the session technical protocol response in the application data channel response message must be identical.

[0189] In step 7b, when the IMS AS determines the Endpoint conversion based on step 7a, if the IMS AS supports the Endpoint information conversion function and / or allows Endpoint conversion by the operator's policy, it can perform an operation to change the Endpoint information within the application data channel related information received from UE #1 from UE to Server (e.g., UE → Server).

[0190] In step 8, the IMS AS can transmit a Session Event Control Notification (SessionEventControl_Notify) message to the DCSF to configure the application data channel for establishing a P2A-based application data channel session by changing the Endpoint information within the application data channel related information received from UE #1 in step 7b from UE to Server. This message includes information such as SessionEstablishmentRequestEvent, Session ID, CallingID, CalledID, SessionCase, Event initiator, MediaInfoList containing changed Endpoint information (e.g., UE → Server), and DC Stream ID.

[0191] FIG. 5b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. Specifically, FIG. 5b may be operations performed after the steps illustrated in FIG. 5a have been performed.

[0192] In step 9, the DCSF, having received a DC control request from the IMS AS in step 8 described in FIG. 5a, can perform policy decisions for a P2A-based application data channel based on relevant parameters within the DC control request message. Additionally, the DCSF can request MF-side MDC2 media information from the MF for the UE to establish an application data channel session using the DC AS. The DCSF can transmit a MediaControl_MediaInstruction message containing information such as MF-side MDC2 media resource request information, SessionID, and MediaInstructionSet to the IMS AS. The DCSF can transmit the MDC2 interface information received from the MF via the IMS AS to the DC AS. Based on the MDC2 interface information received from the DCSF, the DC AS can allocate the DC AS-side MDC2 interface information for a P2A-based application data channel session connection. Subsequently, the DC AS can transmit the MDC2 media endpoint information on the DC AS side to the DCSF. Subsequently, DCSF can update the MDC 2 media endpoint information within MF by transmitting a request for an MF resource update operation to MF through IMS AS based on the MDC 2 media endpoint information received from DCAS. DCSF, having completed the configuration for a P2A-based application data channel session connection, can store media resource information within the response message to the MediaInstruction request received from IMS AS and transmit the response message related to the data channel connection notification (SessionEventControl_Notify) request from IMS AS to IMS AS.

[0193] In step 10, the IMS AS can perform a session connection request message modification operation by removing application-related session technology protocol offers (e.g., SDP offer for application DC & bootstrap DC) from the session connection request message transmitted to UE #2 after recognizing that the request is for a DC interworking-based application data channel connection operation through step 5 described in FIG. 5a.

[0194] In steps 11 and 12, the IMS AS may transmit a session connection request message containing an audio and / or video call related session technology protocol offer to the terminating side network and terminal.

[0195] In step 13, UE #2 and the terminating side network may forward a 200 OK response message containing an audio and / or video call session description protocol response (SDP answer for audio / video) to the originating side IMS AS. Upon receiving the response message containing the audio and / or video call session description protocol response (SDP answer for audio / video) from the terminating side network and UE #2, the IMS AS may forward a Nimsas_SessionEventControl_Notify message to the DCSF containing result information (mediaChangeSuccessEvent), such as that the media change request event has successfully concluded.

[0196] In Step 14, the IMS AS may generate a modified 200 OK response message by adding a bootstrap and application data channel related session technical protocol response (SDP answer for application DC / bootstrap DC) to a 200 OK response message containing an audio and / or video call related session technical protocol response (SDP answer for audio / video) received from UE #2 and the terminating side network. The Endpoint information within the application data channel related session technical protocol response (SDP answer for application DC) in the 200 OK response message may be changed to the Endpoint information originally requested by the terminal (Server → UE) and delivered to UE #1 as a response message for an application data channel session connection request based on a P2P connection type.

[0197] In step 16, the IMS AS can forward a response message to the P-CSCF regarding the application data channel session connection request based on the P2P connection type requested by UE #1. Upon receiving the 200 OK message, the P-CSCF can perform the DC QoS processing operation related to the application data channel session and then forward the 200 OK message to UE #1.

[0198] In step 17, UE #1 can activate the application data channel of the P2A connection type with DC AS through MF.

[0199] In step 18, the DC AS, having received information from the IMS AS that DC interworking operation is required (DC Interworking Required) and information from UE #2 through steps 6a to 6d described in FIG. 5a, recognizes that it must transmit P2A-based application data channel data connected to UE #1 to UE #2 based on the information from UE #2 in the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to UE #2 via a separate message (e.g., SMS). UE #2 can receive information about the data channel application transmitted from UE #1 through the DC AS.

[0200] FIG. 6a is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the IMS AS can determine whether to accept a P2P-based application data channel session connection request message requested by a terminal based on whether it supports changing an Endpoint within the application data channel related information requested by the terminal, in order to support a DC interworking operation using a DC AS based on a P2P-based application data channel session connection request message requested by the terminal. If the IMS AS supports changing an Endpoint within the application data channel related information, the IMS AS can perform an application data channel configuration operation of a P2A connection type based on the changed Endpoint information, change the Endpoint information within the response message delivered to UE #1 to the Endpoint information originally requested by the terminal, and then deliver a response message for the updated application data channel session connection request to UE #1.

[0201] In Step 1, the DC AS can perform a request to subscribe to DC interworking events to the IMS AS. The event subscription request message may include information related to DC interworking, such as specific application information that supports the supported DC interworking (e.g., DC Interworking Information including DC interworking supported Application ID).

[0202] In Step 2, while using a voice or video call-based IMS service with UE #2, UE #1 may request a bootstrap data channel connection operation to download a DC application and receive application-related information for using an IMS DC service with UE #2. At this time, based on the bootstrap data channel connection response message information of UE #2, the DCSF may perform a media resource creation or update operation within the MF considering only the Originating terminal (UE #1) if UE #2 is a terminal that does not support the IMS data channel service (e.g., MTSI UE) or if UE #2 rejects the request for the IMS data channel service. Whether to perform the media resource creation or update operation within the MF considering only the Originating terminal (UE #1) may be determined by the DCSF based on the bootstrap data channel connection response message information of UE #2, according to the subscription information of the Originating terminal (UE #1) and / or the settings of the service provider. If the DCSF supports DC interworking operations based on the subscription information of the originating terminal (UE #1) and / or the service provider's settings, the DCSF can notify UE #1 via the IMS AS that the bootstrap data channel session requested by UE #1 has been successfully established. Subsequently, UE #1 can download data channel applications and data channel application-related information for using the IMS data channel service through the bootstrap data channel.

[0203] In Step 3, UE #1 can transmit a P2P type application data channel session connection request message (re-INVITE) to the network (P-CSCF, S-CSCF, IMS AS) based on the data channel application downloaded through the bootstrap data channel in Step 2. The application-related session technical protocol offer (SDP offer) within the application data channel session connection request message may include at least one piece of information, such as an adc-stream-id and an Application ID, which include Endpoint information. In one embodiment of the present disclosure, UE #1 may include information set as "adc-stream-id-UE" within the application-related session technical protocol offer (SDP offer) for a P2P type application data channel session connection request.

[0204] In Step 4, the IMS AS can select a DCSF (local or remote) to forward the data channel session connection request based on the application-related session technical protocol offer (SDP offer) within the application data channel session connection request message received from UE #1. For example, if the stream-id in the application-related session technical protocol offer (SDP offer) is set to 0, the information for creating the application data channel can be forwarded to the DCSF of the Local Network (e.g., the Originating Network in the case of UE #1). If the stream-id in the application-related session technical protocol offer (SDP offer) is set to 100, the IMS AS can forward the data channel session connection request to the Terminating Network and request the Terminating DCSF to perform the action for creating the application data channel.

[0205] In Step 5, if the stream-id in the application data channel session connection request message received by the IMS AS from UE #1 in the above step is set to 0, the IMS AS may send a Session Event Control Notification (Nimsas_SessionEventControl_Notify) message to the Local (Originating) side DCSF. The Session Event Control Notification message may include at least one of the following: mediaChangeRequestEvent, Session ID, MediaInfoList, EventInitiator, and DC Interworking Information received by the IMS AS from the DC AS.

[0206] In Step 6, the DCSF can determine whether to perform DC interworking based on information for performing application data channel session setup operations received from the IMS AS (e.g., Application ID) and the response message received from UE #2 in Step 2 (port information in the Bootstrap DC-related SDP answer is 0). At this time, the DCSF can determine whether to perform DC interworking by receiving UE #1's subscription information from the HSS and additionally considering whether UE #1 can use the DC interworking service.

[0207] In step 6a, the DCSF may transmit information that DC interworking operation is required (DC Interworking Required or DC Interworking Required via DC AS) and UE #2 side information to the IMS AS via a Session Event Control Notify Response (Nimsas_SessionEventControl_Notify Response) message. The Session Event Control Notify Response (Nimsas_SessionEventControl_Notify Response) message transmitted from the DCSF to the IMS AS may additionally include information that a change based on the P2P application DC type is required (Endpoint change Required or changes P2P application DC to P2A application DC Required).

[0208] In steps 6b through 6e, the IMS AS may transmit to the NEF via the Nimsas_ImsEE_Notify Request message that a DC interworking operation has occurred in accordance with the DC interworking event subscription request received from the DC AS in step 1, and the NEF may transmit the event notification message received from the IMS AS to the DC AS via the Nnef_ImsEE_Notify Request. The notification message may include DC Interworking Required and UE #2 side information. The operations of steps 6b through 6e may be performed after step 7 according to operator policy or settings. Specifically, in step 7, the IMS AS may determine whether to perform the operations of steps 6b through 6e based on the Endpoint information within the application data channel connection request message received from UE #1 through step 4, the DC interworking information received from the DC AS in step 1, or the DC interworking related information received from the DCSF in step 6a, depending on whether to perform a separate Endpoint change operation and whether policy permission is allowed.

[0209] In step 7a, the IMS AS can recognize that an application data channel connection supporting DC interworking using DC AS is required based on the information received from the DCSF in step 6a (DC Interworking Required or DC Interworking Required via DC AS) and the information that changes based on the P2P application DC type are required (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC). The information regarding the requirement for an application data channel connection supporting DC interworking using DC AS can be transmitted from the DCSF to the IMS AS specifically through which network entity the DC interworking is required (e.g., DC Interworking Required via DC AS or DC Interworking Required via MF) within the information that the DC interworking operation is required. Alternatively, the requirement to support DC interworking using DC AS when an event subscription operation is performed from the DC AS can be received from a pre-configured setting or from the DC interworking information transmitted from the DC AS in step 1.An IMS AS that recognizes the need to perform an application data channel connection operation supporting DC interworking using DC AS through DC interworking information transmitted from DC AS in step 1 above or information transmitted from DCSF in step 6a indicating that a change based on the P2A application DC type from the P2P application DC type is required (Endpoint changes Required or Endpoint changes Required from P2P application DC to P2A application DC or DC Interworking Required via DC AS) can check the session technology protocol processing policy of the IMS AS before transmitting an application data channel connection or update request to DCSF based on an application data channel connection request message requested by the terminal. Specifically, after the IMS AS determines whether to convert the Endpoint information within the Application Data Channel connection request message requested by the terminal from a P2P connection type (UE) to a P2A connection type (Server), it can check whether the IMS AS supports the Endpoint conversion function and / or whether the carrier's policy allows the Endpoint conversion. The determination of the Endpoint conversion operation by the IMS AS and the acceptance or rejection of the Application Data Channel of the connection type requested by UE #1 may occur due to the constraint that the information within the session technical protocol offer in the Application Data Channel request message and the information (e.g., Endpoint) within the session technical protocol response in the Application Data Channel response message must be identical.

[0210] In step 7b, after determining the transformation of Endpoint information in the IMS AS in step 7a, if the IMS AS checks whether it supports the Endpoint transformation function and / or the operator's policy, and if the Endpoint transformation is allowed in the IMS AS, it can perform the operation of changing the Endpoint information in the application data channel related information received from UE #1 from UE to Server.

[0211] In step 8, the IMS AS can transmit a Session Event Control Notification (SessionEventControl_Notify) message to the DCSF to configure the application data channel for establishing a P2A-based application data channel session by changing the Endpoint information within the application data channel related information received from UE #1 in step 7b from UE to Server. This message includes information such as SessionEstablishmentRequestEvent, Session ID, CallingID, CalledID, SessionCase, Event initiator, MediaInfoList containing the changed Endpoint information, and DC Stream ID.

[0212] FIG. 6b is a flowchart of an application data channel connection operation that supports DC interworking using a DC AS according to an embodiment of the present disclosure. Specifically, FIG. 6b may be operations performed after the steps illustrated in FIG. 6a have been performed.

[0213] According to one embodiment of the present disclosure, in step 9 following step 8 described in FIG. 6a, a DCSF that has received a DC control request from an IMS AS can perform a policy decision for a P2A-based application data channel based on relevant parameters within the DC control request message. Additionally, the DCSF can request MF-side MDC2 media information from the MF for a UE to establish an application data channel session using the DC AS. The DCSF can transmit a MediaControl_MediaInstruction message to the IMS AS that includes information such as MF-side MDC2 media resource request information, SessionID, and MediaInstructionSet. The DCSF can transmit MDC2 interface information received from the MF via the IMS AS to the DC AS. Based on the MDC2 interface information received from the DCSF, the DC AS can allocate DC AS-side MDC2 interface information for a P2A-based application data channel session connection. Subsequently, the DC AS can transmit MDC2 media endpoint information on the DC AS side to the DCSF. Subsequently, DCSF can update the MDC 2 media endpoint information within MF by transmitting a request for an MF resource update operation to MF through IMS AS based on the MDC 2 media endpoint information received from DCAS. DCSF, having completed the configuration for a P2A-based application data channel session connection, can store media resource information within the response message to the MediaInstruction request received from IMS AS and transmit the response message related to the data channel connection notification (SessionEventControl_Notify) request from IMS AS to IMS AS.

[0214] In step 10, the IMS AS can perform a session connection request message modification operation by removing application-related session technology protocol offers (e.g., SDP offer for application DC & bootstrap DC) from the session connection request message transmitted to UE #2 after recognizing that the request is for a DC interworking-based application data channel connection operation through step 5 described in FIG. 6a.

[0215] In steps 11 and 12, the IMS AS may transmit a session connection request message containing an audio and / or video call related session technology protocol offer to the terminating side network and terminal.

[0216] In step 13, UE #2 and the terminating side network may forward a 200 OK response message containing an audio and / or video call session description protocol response (SDP answer for audio / video) to the originating side IMS AS. Upon receiving the response message containing the audio and / or video call session description protocol response (SDP answer for audio / video) from the terminating side network and UE #2, the IMS AS may forward a Nimsas_SessionEventControl_Notify message to the DCSF containing result information (mediaChangeSuccessEvent), such as that the media change request event has successfully concluded.

[0217] In Step 14, the IMS AS may generate a modified 200 OK response message by adding a bootstrap and application data channel related session technical protocol response (SDP answer for application DC / bootstrap DC) to a 200 OK response message containing an audio and / or video call related session technical protocol response (SDP answer for audio / video) received from UE #2 and the terminating side network. The Endpoint information within the application data channel related session technical protocol response (SDP answer for application DC) in the 200 OK response message may be changed to the Endpoint information originally requested by the terminal (Server → UE) and delivered to UE #1 as a response message for an application data channel session connection request based on a P2P connection type.

[0218] In step 16, the IMS AS can forward a response message to the P-CSCF regarding the application data channel session connection request based on the P2P connection type requested by UE #1. Upon receiving the 200 OK message, the P-CSCF can perform the DC QoS processing operation related to the application data channel session and then forward the 200 OK message to UE #1.

[0219] In step 17, UE #1 can activate the application data channel of the P2A connection type with DC AS through MF.

[0220] In step 18, the DC AS, having received information from the IMS AS that DC interworking operation is required (DC Interworking Required) and information from UE #2 through steps 6b to 6e described in FIG. 6a, recognizes that it must transmit P2A-based application data channel data connected to UE #1 to UE #2 based on the information from UE #2 in the event notification message, and can transmit the URL of the application data channel information transmitted from UE #1 to the DC AS to UE #2 via a separate message (e.g., SMS). UE #2 can receive information about the data channel application transmitted from UE #1 through the DC AS.

[0221] FIG. 7 illustrates the structure of a terminal according to one embodiment of the present disclosure.

[0222] Referring to FIG. 7, the terminal may include a transceiver (710), a control unit (720), and a storage unit (730). The transceiver (710), the control unit (720), and the storage unit (730) may operate according to the communication method of the terminal described above. However, the components of the terminal are not limited to the examples described above. For example, the terminal may include more components or fewer components than the components described above. For example, the terminal may include a transceiver (710) and a control unit (720). In addition, the transceiver (710), the control unit (720), and the storage unit (730) may be implemented in the form of a single chip.

[0223] The transceiver (710) is a collective term for the receiving unit and the transmitting unit of a terminal, and can transmit and receive signals with a base station, another terminal, or a network entity. The signals transmitted and received with the base station may include control information and data. For example, the transceiver (710) can receive system information from the base station and can receive synchronization signals or reference signals. To this end, the transceiver (710) may be composed of an RF transmitter that up-converts and amplifies the frequency of the transmitted signal, and an RF receiver that low-noise amplifies the received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (710), and the components of the transceiver (710) are not limited to the RF transmitter and the RF receiver. Additionally, the transceiver (710) may include a wired / wireless transceiver and may include various configurations for transmitting and receiving signals. Additionally, the transceiver (710) can receive a signal through a wireless channel and output it to the control unit (720), and transmit the signal output from the control unit (720) through the wireless channel. Additionally, the transceiver (710) can receive a communication signal and output it to a processor, and transmit the signal output from the processor to a network entity through a wired or wireless network.

[0224] The storage unit (730) can store programs and data necessary for the operation of the terminal. Additionally, the storage unit (730) can store control information or data included in signals obtained from the terminal. The storage unit (730) may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD.

[0225] In the present disclosure, the control unit (720) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The processor may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as applications. The control unit (720) may control the overall operation of the terminal according to the embodiment proposed in the present disclosure. For example, the control unit (720) may control the signal flow between each block to perform operations according to the flowchart described above.

[0226] FIG. 8 illustrates the structure of a base station according to one embodiment of the present disclosure.

[0227] Referring to FIG. 8, the base station may include a transceiver (810), a control unit (820), and a storage unit (830). The transceiver (810), the control unit (820), and the storage unit (830) may operate according to the communication method of the base station described above. A network device may also correspond to the structure of the base station. However, the components of the base station are not limited to the examples described above. For example, the base station may include more components or fewer components than the components described above. For example, the base station may include a transceiver (810) and a control unit (820). Furthermore, the transceiver (810), the control unit (820), and the storage unit (830) may be implemented in the form of a single chip.

[0228] The transceiver (810) collectively refers to the receiver and the transmitter of a base station and can transmit and receive signals with a terminal, another base station, or other network devices. At this time, the signals transmitted and received may include control information and data. For example, the transceiver (810) can transmit system information to a terminal and transmit a synchronization signal or a reference signal. To this end, the transceiver (810) may be composed of an RF transmitter that up-converts and amplifies the frequency of the transmitted signal, and an RF receiver that low-noise amplifies the received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (810), and the components of the transceiver (810) are not limited to an RF transmitter and an RF receiver. The transceiver (810) may include a wired / wireless transceiver and may include various configurations for transmitting and receiving signals. Additionally, the transceiver (810) can receive a signal through a communication channel (e.g., a wireless channel) and output it to a control unit (820), and transmit the signal output from the control unit (820) through the communication channel. Additionally, the transceiver (810) can receive a communication signal and output it to a processor, and transmit the signal output from the processor to a terminal, another base station, or another entity through a wired or wireless network.

[0229] The storage unit (830) can store programs and data necessary for the operation of the base station. Additionally, the storage unit (830) can store control information or data included in signals obtained from the base station. The storage unit (830) may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD. Additionally, the storage unit (830) can store at least one of information transmitted and received through the transmission and reception unit (810) and information generated through the control unit (820).

[0230] In the present disclosure, the control unit (820) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The processor may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as applications. The control unit (820) may control the overall operation of a base station according to an embodiment proposed in the present disclosure. For example, the control unit (820) may control the signal flow between each block to perform operations according to the flowchart described above.

[0231] FIG. 9 illustrates the structure of a network entity according to one embodiment of the present disclosure.

[0232] A network entity according to one embodiment of the present disclosure may include a control unit (920) that controls the overall operation of the network entity, a transmitting and receiving unit (910) including a transmitting unit and a receiving unit, and a storage unit (930). Of course, it is not limited to the above examples, and the network entity may include more or fewer configurations than the configuration shown in FIG. 9.

[0233] According to one embodiment of the present disclosure, the transmitting and receiving unit (910) may transmit and receive a signal with at least one of other network entities or terminals. The signal transmitted and received with at least one of other network entities or terminals may include control information and data.

[0234] According to one embodiment of the present disclosure, the control unit (920) can control a network entity to perform any one of the above-described embodiments. Meanwhile, the control unit (920), the storage unit (930), and the transmission / reception unit (910) do not necessarily have to be implemented as separate modules, and can be implemented as a single component in the form of a single chip. Also, the control unit (920) and the transmission / reception unit (910) can be electrically connected. Furthermore, the control unit (920) may be an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, or at least one processor.

[0235] According to one embodiment of the present disclosure, the storage unit (930) may store data such as a basic program, an application program, and configuration information for the operation of a network entity. In particular, the storage unit (930) provides the stored data upon a request from the control unit (920). The storage unit (930) may be composed of a storage medium or a combination of storage media such as ROM, RAM, a hard disk, a CD-ROM, and a DVD. Additionally, the storage unit (930) may be a plurality of units. Furthermore, the control unit (920) may execute the aforementioned embodiments based on a program for executing the aforementioned embodiments of the present disclosure stored in the storage unit (930).

[0236] Meanwhile, the order of description in the drawings illustrating the method proposed in this disclosure does not necessarily correspond to the order of execution, and the order of execution may be changed or executed in parallel. Alternatively, the drawings illustrating the method proposed in this disclosure may omit some components and include only some components to the extent that the essence of this disclosure is not compromised.

[0237] Methods according to the claims or embodiments described in the specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0238] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the claims or embodiments described in the specification of this disclosure.

[0239] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), magnetic disc storage devices, CD-ROM (Compact Disc-ROM), Digital Versatile Discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0240] Additionally, the program may be stored on an attachable storage device accessible via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), or Storage Area Network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present disclosure.

[0241] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0242] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

1. In the method of operation of an IMS AS (IP Multimedia Subsystem Application Server) in a wireless communication system, A step of receiving a request message from a first UE (user equipment) requesting to establish an application data channel with a second UE as a P2P (Peer-to-Peer) application data channel; A step of transmitting a session event control notification message containing information about the P2P application data channel to the DCSF (Data Channel Server Function); A step of receiving a message from the above DCSF including change instruction information instructing to change the P2P application data channel to a P2A (Person-to-Application) application data channel; and A method comprising the step of changing the endpoint of the application data channel to the endpoint of the server based on the above change instruction information.

2. In Paragraph 1, A method characterized in that the above request message includes a data channel-related session description protocol (SDP) containing information about the application data channel.

3. In Paragraph 2, A method further comprising the step of determining the refusal to establish the P2P application data channel when the information included in the SDP of the request message above cannot be changed by the IMS AS.

4. In Paragraph 3, A method further comprising the step of receiving a request message for establishing a P2A application data channel from the first UE in response to the refusal to establish the P2P application data channel.

5. In claim 2, the step of changing the endpoint is, A method characterized by including the step of modifying the endpoint information included in the SDP of the request message to the endpoint information of the server based on the above change instruction information.

6. In Paragraph 1, A method in which a message containing the above change instruction information further includes information that DC (Data Channel) interworking is required.

7. In Paragraph 6, A method further comprising the step of transmitting a notification message to a Network Exposure Function (NEF), the message including information about a DC interworking request event and information about the second UE, based on information that the above DC interworking is required.

8. In the method of operation of the DCSF (Data Channel Server Function) in a wireless communication system, A step of receiving a session event control notification message from an IMS AS (IP Multimedia Subsystem Application Server) containing information about a P2P (Peer-to-Peer) application data channel between a first UE and a second UE; A step of determining to change the P2P application data channel to a P2A (Person-to-Application) application data channel based on at least one of application information regarding the application data channel or information regarding the second UE; and The method includes the step of transmitting a message containing change instruction information instructing the above IMS AS to change the above P2P application data channel to the above P2A application data channel, and A method characterized by changing the endpoint of the P2P application data channel to the endpoint of the server by the IMS AS based on the above change instruction information.

9. In Paragraph 8, A method in which a message containing the above change instruction information further includes information that DC (Data Channel) interworking is required.

10. In Paragraph 9, A method characterized in that the information that the above DC interworking is required serves as the basis for the above IMS AS to transmit information about the DC interworking request event to the NEF (Network Exposure Function).

11. In an IMS AS (IP Multimedia Subsystem Application Server) in a wireless communication system, At least one processor; and It includes at least one memory that is communicationally coupled to the above at least one processor and stores instructions, and The above instructions are executed individually or in any combination by the above at least one processor, so that the above IMS AS: A request message is received from the first UE (user equipment) requesting to establish an application data channel with the second UE as a P2P (Peer-to-Peer) application data channel, and Send a session event control notification message containing information about the above P2P application data channel to the DCSF (Data Channel Server Function), and A message is received from the above DCSF containing change instruction information instructing to change the P2P application data channel to a P2A (Person-to-Application) application data channel, and IMS AS that changes the endpoint of the application data channel to the server endpoint based on the above change instruction information.

12. In Paragraph 11, The above request message is characterized by including a data channel-related session description protocol (SDP) that includes information about the application data channel, in an IMS AS.

13. In claim 12, the above instructions are performed by the at least one processor, the IMS AS: An IMS AS characterized by determining to reject the establishment of the P2P application data channel when the information included in the SDP of the above request message cannot be changed by the IMS AS.

14. In claim 13, the instructions are performed by the at least one processor, the IMS AS: IMS AS characterized by receiving a request message for establishing a P2A application data channel from the first UE in response to the refusal to establish the above P2P application data channel.

15. In the Data Channel Server Function (DCSF) of a wireless communication system, At least one processor; and It includes at least one memory that is communicationally coupled to the above at least one processor and stores instructions, and The above instructions are executed individually or in any combination by the above at least one processor, so that the DCSF: Receive a session event control notification message from the IMS AS (IP Multimedia Subsystem Application Server) containing information about a P2P (Peer-to-Peer) application data channel between the first UE and the second UE, and Based on at least one of application information regarding the application data channel or information regarding the second UE, it is decided to change the P2P application data channel to a P2A (Person-to-Application) application data channel, and To transmit to the above IMS AS a message containing change instruction information instructing to change the above P2P application data channel to the above P2A application data channel, and DCSF characterized by the fact that, based on the above change instruction information, the endpoint of the P2P application data channel is changed to the server endpoint by the above IMS AS.

Images