Method and apparatus for providing IMS data channel-based service experience in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. According to various embodiments of the present disclosure, a method performed by a data channel (DC) application server (AS) entity in a mobile communication system may comprise the steps of: transmitting, to an internet protocol (IP) multimedia subsystem (IMS) application server (AS) entity, a first message for subscribing to an event associated with DC interworking of a multimedia telephony service for IMS (MTSI) user equipment (UE); receiving, from the IMS AS entity, a second message for notifying the DC interworking for a DC MTSI UE; and transmitting, to the MTSI UE, information for accessing a DC AS.

Description

Method and device for providing IMS data channel-based service experience in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more particularly, to a method and apparatus for providing an IMS data channel-based service experience.

[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 the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

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

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] To meet the growing demand for wireless data traffic following the commercialization of 4G communication systems, efforts are being made to develop improved 5G or pre-5G communication systems. For this reason, 5G or pre-5G communication systems are also referred to as "Beyond 4G Network" or "Post-LTE" systems. The 5G communication system specified by 3GPP is called the New Radio (NR) system.

[0009] To achieve high data rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., the 60 GHz band). To mitigate radio path loss and increase the transmission range of radio waves in ultra-high frequency bands, beamforming, massive MIMO (massive MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antenna technologies have been discussed and applied to NR systems in 5G communication systems.

[0010] Additionally, to improve the network of the system, technologies such as evolved small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, moving networks, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation are being developed in 5G communication systems.

[0011] In addition, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed in 5G systems.

[0012] Meanwhile, the Internet is evolving from a human-centric network where humans create and consume information to an Internet of Things (IoT) network where information is exchanged and processed between distributed components, such as objects. The Internet of Everything (IoE) is also emerging, combining IoT technologies with big data processing technologies, such as those connected to cloud servers. To implement the IoT, technological elements such as sensing technologies, wireless and wired communication and network infrastructure, service interface technologies, and security technologies are required. Recently, research is being conducted on technologies such as sensor networks, Machine-to-Machine (M2M), and Machine-Type Communication (MTC) for connecting objects. In the IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated from connected objects to create new value for human life. IoT can be applied to areas such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services through the convergence and integration of existing IT (Information Technology) technologies with various industries.

[0013] Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, 5G communication such as sensor networks, machine-to-machine (M2M), and machine-type communication (MTC) are being implemented using techniques such as beamforming, MIMO, and array antennas. The application of cloud radio access networks (cloud RAN), a big data processing technology described above, can also be considered an example of the convergence of 5G and IoT technologies.

[0014] The present invention relates to wireless communication systems, and more particularly, to methods and devices for providing a service experience based on an IMS (Internet Protocol Multimedia Subsystem) data channel. Specifically, embodiments of the present disclosure propose various methods for establishing a connection based on an IMS data channel.

[0015] Conventional IMS data channel-based multimedia calls can be made by checking during the call establishment procedure whether the status and conditions of the terminal and 5G network are in a state and condition that can provide an IMS data channel-based multimedia call, and if the conditions cannot be met, the call is not established, or after the call is established, monitoring is performed and if the conditions cannot be met, the call is released.

[0016] In the case of IMS data channel-based multimedia call services currently being discussed in 3GPP, there is a growing requirement that services be provided without restrictions between users using terminals that do not support IMS data channels and users using terminals that support IMS data channels.

[0017] Therefore, a method is required to provide an IMS data channel-based service experience by providing a method for terminals that do not support IMS data channels to connect to a server that provides IMS data channel-based services indirectly without directly using the IMS data channel.

[0018] According to various embodiments of the present disclosure, an object is to provide a device and method capable of effectively providing a service in a wireless communication system.

[0019] The technical problems to be achieved in this document are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0020] According to various embodiments of the present disclosure, in a wireless communication system, a method performed by a user equipment (UE) may include the steps of receiving a configuration message from a base station, measuring a channel based on the configuration message, and transmitting the measurement result to the base station.

[0021] According to various embodiments of the present disclosure, a method is provided for a terminal that does not support an IMS data channel to be connected to a server that provides an IMS data channel-based service indirectly without directly using an IMS data channel, thereby proposing an IMS session and an IMS data channel session establishment procedure that can provide an IMS data channel-based service experience.

[0022] The present disclosure provides a device and method capable of effectively providing a service in a wireless communication system.

[0023] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0024] FIG. 1 illustrates the structure of a 5G system according to embodiments of the present disclosure.

[0025] FIG. 2 illustrates an IMS (IP (internet protocol) multimedia subsystem) network structure according to embodiments of the present disclosure.

[0026] FIGS. 3A and 3B illustrate the structure of a network including a data channel server in a wireless communication system according to embodiments of the present disclosure.

[0027] FIG. 4 illustrates a network structure including a connection between a core network and an IMS network in a wireless communication system according to embodiments of the present disclosure.

[0028] FIG. 5 illustrates a signal flow for providing an IMS data channel service experience in a wireless communication system according to embodiments of the present disclosure.

[0029] FIG. 6A and FIG. 6B illustrate another signal flow for providing an IMS data channel service experience in a wireless communication system according to embodiments of the present disclosure.

[0030] FIG. 7A and FIG. 7B illustrate another signal flow for providing an IMS data channel service experience in a wireless communication system according to embodiments of the present disclosure.

[0031] FIG. 8 illustrates a configuration of a terminal according to various embodiments of the present disclosure.

[0032] FIG. 9 illustrates a configuration of a base station according to various embodiments of the present disclosure.

[0033] The operating principle of the present invention will be described in detail with reference to the attached drawings below.

[0034] In describing the embodiments, descriptions of technical details that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to ensure that the gist of the present disclosure is conveyed more clearly without obscuring it by omitting unnecessary explanations.

[0035] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0036] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the present disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined solely by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0037] At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0038] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0039] Here, the term '~ unit' used in this embodiment means a software or hardware component such as an FPGA or ASIC, and the '~ unit' performs certain roles. However, the '~ unit' is not limited to software or hardware. The '~ unit' may be configured to be on an addressable storage medium and may be configured to regenerate one or more processors. Thus, as an example, the '~ unit' includes components such as software components, object-oriented software components, class components, and task components, 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 '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. In addition, the components and '~ units' may be implemented to regenerate one or more CPUs within a device or a secure multimedia card. Additionally, in the embodiment, '~bu' may include one or more processors.

[0040] The terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, and terms referring to various identification information are provided for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms referring to objects with equivalent technical meanings may be used.

[0041] For convenience of explanation, this disclosure uses terms and names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP) LTE (3rd Generation Partnership Project Long Term Evolution) standard and the 3GPP 5G standard. However, the present invention is not limited to these terms and names and can be equally applied to systems conforming to other standards.

[0042] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the attached drawings. It should be noted that, where possible, identical components are represented by identical reference numerals throughout the attached drawings. Furthermore, the attached drawings of the present disclosure are provided to aid understanding of the present disclosure, and it should be noted that the present invention is not limited to the forms or arrangements illustrated in the drawings.

[0043] FIG. 1 illustrates the structure of a 5G system according to embodiments of the present disclosure.

[0044] Referring to FIG. 1, the 5G system architecture may include various components (e.g., network functions (NFs)). FIG. 1 illustrates some of them, including an authentication server function (AUSF) device (110), an access and mobility management function (AMF) device (103), a session management function (SMF) device (104), a policy control function (PCF) device (107), an application function (AF) device (108), a unified data management (UDM) device (106), a data network (DN) (112), a user plane function (UPF) device (105), a (radio) access network (R)AN) (102), and a terminal (e.g., a user equipment (UE)) (101). In addition, in FIG. 1, a Network Slice Selection Function (NSSF) device (109) and a Network Slice Specific Authentication and Authorization Function (NSSAAF) device (111) are exemplarily illustrated.

[0045] Each of the devices illustrated in FIG. 1 may be implemented as a single server or device, or as a network slice instance. When implemented as a network slice instance, two or more identical or different network slice instances may be implemented within a single server or device, or a single network slice instance may be implemented across two or more servers or devices.

[0046] Each NF can support the following functions:

[0047] - AUSF (110) can process and store data for UE authentication.

[0048] - AMF (103) can provide functions for access and mobility management per UE, and one UE can be connected to one AMF by default. Specifically, the AMF (103) provides signaling between core network (CN) nodes for mobility between 3GPP access networks, termination of a radio access network (RAN) control plane (CP) interface (e.g., N2 interface), termination (N1) of non-access stratum (NAS) signaling, NAS signaling security (NAS ciphering and integrity protection), access stratum (AS) security control, registration management (registration area management), connection management, idle mode UE reachability (including control and performance of paging retransmission), mobility management control (e.g., subscription and policy), intra-system mobility and inter-system mobility support, support for network slicing, SMF selection, lawful intercept (e.g., for AMF events and interfaces to the LI system), and delivery of session management (SM) messages between the UE and the SMF. It may support functions such as provision, transparent proxy for SM message routing, access authentication, access authorization including roaming permission check, provision of SMS message delivery between UE and Short Message Service Function (SMSF), security anchor function (SAF) and / or security context management (SCM).Some or all of these AMF (103) functions may be supported within a single AMF instance operating as one AMF.

[0049] - DN (112) may mean, for example, an operator service, Internet access, or a third-party service. DN (112) may transmit a downlink protocol data unit (PDU) to UPF (105) or receive a PDU transmitted from UE (101) through UPF (105).

[0050] - PCF (107) can receive information about packet flow from an application server and provide a function to determine policies such as mobility management and session management. Specifically, PCF (107) can support functions such as supporting a unified policy framework for controlling network operations, providing policy rules so that control plane function(s) (e.g., AMF, SMF, etc.) can enforce the policy rules, and implementing a front end for accessing related subscription information for policy determination within a user data repository (UDR).

[0051] - SMF (104) provides session management function, and when UE has multiple sessions, each session can be managed by a different SMF. Specifically, SMF (104) can support functions such as session management (e.g., session establishment, modification and termination including tunnel maintenance between UPF and AN node), UE IP address allocation and management (optionally including authentication), selection and control of UP functions, traffic steering setup for routing traffic from UPF to appropriate destinations, termination of interfaces towards policy control functions, enforcement of control part of policies and quality of service (QoS), lawful intercept (for SM events and interfaces to LI system), termination of SM part of NAS messages, downlink data notification, initiator of AN specific SM information (delivered to AN via N2 via AMF), determination of SSC mode of session, roaming function, etc. As described above, some or all of the functions of SMF (104) may be supported within a single SMF instance that operates as one SMF.

[0052] - UDM (106) can store user subscription data, policy data, etc. UDM (106) can include two parts, namely, an application front end (FE) (not shown) and a user data repository (UDR) (not shown).

[0053] - The FE may include a UDM FE, which is responsible for location management, subscription management, and credential processing, and a PCF-FE, which is responsible for policy control. The UDR may store data required for the functions provided by the UDM-FE and policy profiles required by the PCF. The data stored in the UDR may include user subscription data and policy data, including subscription identifiers, security credentials, access and mobility-related subscription data, and session-related subscription data. The UDM-FE may access subscription information stored in the UDR and support functions such as authentication credential processing, user identification handling, access authentication, registration / mobility management, subscription management, and SMS management.

[0054] - UPF (105) can transmit a downlink PDU received from DN (112) to UE (101) via (R)AN (102), and can transmit an uplink PDU received from UE (101) via (R)AN (102) to DN (112). Specifically, the UPF (105) may support an anchor point for intra / inter RAT mobility, an external PDU session point for interconnection to a Data Network, a user plane portion of packet routing and forwarding, packet inspection and policy rule enforcement, an uplink classifier to support lawful intercept, traffic usage reporting, routing of traffic flows to the Data Network, a branching point to support multi-homed PDU sessions, QoS handling for the user plane (e.g., packet filtering, gating, uplink / downlink rate enforcement), uplink traffic validation (service data flow (SDF) mapping between SDFs and QoS flows), transport level packet marking in uplink and downlink, downlink packet buffering and downlink data notification triggering functions, etc. Some or all of these functions of UPF (105) may be supported within a single UPF instance operating as a single UPF.

[0055] - AF (108) can interact with the 3GPP core network to provide services (e.g., support functions such as application impact on traffic routing, access to network capability exposure, and interaction with policy frameworks for policy control).

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

[0057] - gNB (gNode B) can refer to a base station. A base station can include terms such as RAN and TRP (transmission reception point). Functions for radio resource management (e.g., radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to UE in uplink / downlink (e.g., scheduling)), IP (internet protocol) header compression, encryption and integrity protection of user data streams, selection of AMF (103) upon attachment of UE (101) if routing to AMF (103) is not determined from information provided to UE (101), routing of user plane data to UPF (105)(s), routing of control plane information to AMF (103), connection setup and teardown, scheduling and transmission of paging messages (originating from AMF), scheduling and transmission of system broadcast information (originating from AMF or operating and maintenance (O&M)), measurement and measurement reporting setup for mobility and scheduling, It can support functions such as transport level packet marking in uplink, session management, support for network slicing, QoS flow management and mapping to data radio bearers, support for UEs in inactive mode, NAS message distribution, NAS node selection, radio access network sharing, dual connectivity, and tight interworking between NR and E-UTRA.

[0058] - UE (101) may refer to a user equipment. The user equipment may be referred to by terms such as terminal, mobile equipment (ME), and mobile station (MS). In addition, the user equipment may be a portable device such as a laptop, mobile phone, personal digital assistant (PDA), smartphone, multimedia device, or a non-portable device such as a personal computer (PC) or vehicle-mounted device. Hereinafter, the user equipment (UE) or terminal will be referred to as such.

[0059] In one embodiment, for clarity of explanation, a network exposure function (NEF) device and an NF repository function (NRF) device are not illustrated in FIG. 1, but all NFs illustrated in FIGS. 2 to 7b, which will be described later, may interact with the NEF and NRF as needed. Specifically, the NRF (not illustrated in FIG. 1) may support a service discovery function. When the NRF receives a second NF discovery request from a first NF instance, the NRF may perform a second NF discovery operation and then provide information about the discovered second NF instance to the first NF instance. In addition, the NRF may maintain available NF instances and the services they support.

[0060] Meanwhile, for convenience of explanation, FIG. 1 illustrates a reference model for a case where a UE accesses one DN using one PDU (protocol data unit) session, but the present disclosure is not limited thereto.

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

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

[0063] In one embodiment, the control plane components of 5GC can be considered as virtualized network functions (VNFs), and communication between VNFs can be considered as one VNF providing services to other VNFs through the exchange of RESTful-based application programming interfaces (APIs). This API-based communication interface between VNFs is called a Service Based Interface (SBI).

[0064] In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. The following illustrates a reference point included in the 5G system architecture depicted in Figure 1.

[0065] - N1: Reference point between UE and AMF

[0066] - N2: Reference point between (R)AN and AMF

[0067] - N3: Reference point between (R)AN and UPF

[0068] - N4: Reference point between SMF and UPF

[0069] - N5: Reference point between PCF and AF

[0070] - N6: Reference point between UPF and data network

[0071] - N7: Reference point between SMF and PCF

[0072] - N8: Reference point between UDM and AMF

[0073] - N9: Reference point between two core UPFs

[0074] - N10: Reference point between UDM and SMF

[0075] - N11: Reference point between AMF and SMF

[0076] - N12: Reference point between AMF and AUSF

[0077] - N13: Reference point between UDM and authentication server function (AUSF)

[0078] - N14: Reference point between two AMFs

[0079] - N15: Reference point between PCF and AMF for non-roaming scenarios, reference point between PCF and AMF in visited network for roaming scenarios.

[0080] In the following description, the term "terminal" may refer to UE (101), and the terms "UE" and "terminal" may be used interchangeably. In this case, unless specifically defined additionally, the term "terminal" should be understood as "UE (101).

[0081] A terminal establishes a session by connecting to a data network (e.g., a network providing Internet services) through a 5G system, and can distinguish each data network using an identifier called a Data Network Name (DNN). The DNN can be used to determine NFs, inter-NF interfaces, and operator policies related to the user plane when the terminal connects to a network system and a session. For example, the DNN can be used to select SMFs and UPF(s) for a PDU session, and to select interface(s) (e.g., N6 interface) between a data network and UPF for a PDU session. In addition, the DNN can be used to determine a mobile communication operator's policy to be applied to a PDU session.

[0082] FIG. 2 illustrates an IMS (Internet Protocol (IP) multimedia subsystem) network structure according to embodiments of the present disclosure. According to one embodiment, reference is made to the contents of FIG. 1, and redundant descriptions may be omitted.

[0083] Referring to FIG. 2, a UE (User Equipment) (101) can communicate with other UEs (not shown) located in a remote IMS network (260) and IM CN subsystem components through an IM CN (IP Multimedia Core Network) subsystem. The IM CN subsystem can include a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230), an IMS HSS (240), an IMS AGW (250), and / or an MRF (270), and the above-described components can perform the following functions.

[0084] - P-CSCF (Proxy Call Session Control Function) (210): P-CSCF can perform the function of the first contact point for UE to access IMS.

[0085] - I / S-CSCF (Interrogating / Serving CSCF) (220): The I-CSCF can perform the function of a contact point for subscribers of a network operator or roaming users currently located in the service area of ​​the network operator. In one embodiment, the S-CSCF can handle the actual user session state of the network.

[0086] - IMS AS (Application Server) (230): The IMS AS can provide and execute IM (Internet Multimedia) value-added services. In one embodiment, the IMS AS can also influence SIP (Session Initiation Protocol) sessions by acting on behalf of services supported in the operator network.

[0087] - IMS HSS (Home Subscriber Server) (240): IMS HSS can act as a database that stores information about users.

[0088] - IMS-AGW (Access Gateway) (250): IMS-AGW is located in the media transmission path and can manage network addresses associated with inbound and outbound media streams.

[0089] - MRF (Media Resource Function) (270): The MRF can perform various processing tasks related to media streams. According to one embodiment, the MRF can be divided into an MRFC (Multimedia Resource Function Controller) responsible for control and an MRFP (Multimedia Resource Function Processor) responsible for media processing.

[0090] With reference to FIG. 2, the interfaces between the above-described components can be expressed by the following reference points.

[0091] - Gm: Reference point Gm can support communication between the UE and the IM CN subsystem. For example, the UE can request network registration and session control via the Gm reference point. In one embodiment, SIP, described below, can be used for the Gm reference point.

[0092] - Mw: Reference point Mw can support the exchange and transmission of signaling messages between CSCFs.

[0093] - ISC: Reference Point ISC can support the exchange of information required for services provided by the service platform between the S-CSCF and the service platform (e.g., IMS AS).

[0094] - Sh: Reference point Sh can support the exchange of information required for services provided by the service platform between the HSS and the service platform (e.g., IMS AS).

[0095] - Cx: Reference point Cx can support information transfer between HSS and CSCF.

[0096] - Mr' / Cr: Reference point Mr' can support interaction for session control between IMS AS and MRFC. Reference point Cr can support interaction for media control between IMS AS and MRFC.

[0097] - Iq: Reference point Iq can support the exchange of information required for allocation and release of transport addresses between P-CSCF and IMS AGW.

[0098] - Mb: Reference point Mb can support IMS media transfer between IMS components.

[0099] Referring to FIG. 2, a P-CSCF (210) supporting a Service Based Interface (SBI) can communicate with a Policy Control Function (PCF) (107), which can be represented by reference point N5. According to one embodiment, the PCF (107) can support policy establishment and distribution for managing network operations. According to one embodiment, the P-CSCF (210) supporting SBI can be considered an application function (AF) that uses the service provided by the PCF (107) to other VNFs.

[0100] In one embodiment, an HSS (240) supporting SBI may communicate with an I / S-CSCF (220) supporting SBI via reference point N70 and may communicate with an IMS AS (230) supporting SBI via reference point N71. Similarly, an I / S-CSCF (220) supporting SBI and an IMS AS (230) supporting SBI may be considered as AFs that use services provided by an HSS (240) supporting SBI. In one embodiment, the functions provided by reference points N70 and N71 may be equivalent to the functions provided by reference points Cx and Sh, respectively.

[0101] In one embodiment, SIP may refer to an application layer signaling protocol that specifies procedures for intelligent terminals wishing to communicate on the Internet to identify each other, locate each other, and create, delete, or modify multimedia communication sessions between them. In one embodiment, SIP is a request / response structure that controls the creation, modification, and termination of multimedia service sessions such as Internet-based conferences, telephones, voice mail, event notifications, and instant messaging, and can be applied to both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). In addition, SIP can provide services independent of IP addresses by using a SIP Uniform Resource Locator (URL), which is similar to an email address, to distinguish each user. In one embodiment, SIP is text-based and was developed using many parts of Hyper Text Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), making it easy to implement, and it can be combined with many other protocols used on the Internet to provide various services, providing flexibility and extensibility. SIP is a simpler protocol corresponding to ITU-T's H.323. It was proposed as RFC 2543 by the IETF MMUSIC (Multiparty Multimedia Session Control) Working Group in 1999, and later revised by a separate ITEF SIP Working Group, and the RFC3261 standard was established in July 2002.

[0102] In order to provide a service (e.g., a real-time interaction service) in a communication system according to various embodiments of the present disclosure, agreement on a media session configuring the service is required between user UEs participating in the service. The communication system according to various embodiments of the present disclosure can achieve agreement on a media session through Session Description Protocol (SDP) negotiation to provide a service (e.g., a real-time interaction service).

[0103] In one embodiment, SDP may be included in a SIP message. SDP may include an ASCII-based protocol for describing a multimedia session and related scheduling information. SDP is intended to convey information about the media streams of a multimedia session so that a session can be joined. A multimedia session may be defined as a set of media streams over a period of time, and the duration of the session need not be continuous. A multicast-based session on the Internet may fundamentally have two purposes: a means of announcing the existence and duration of the session and a means of conveying session joining information. In a unicast environment, the latter may be the purpose. In one embodiment, the content of the SDP information may include the name and purpose of the session, the duration of the session, the session configuration medium, and media reception information.

[0104] Below, various embodiments of the present disclosure are described on the assumption that the service provided in the communication system is a real-time interaction service, but of course, the present disclosure is not limited thereto.

[0105] Figures 3a and 3b illustrate the structure of a network including a data channel server in a wireless communication system according to embodiments of the present disclosure. Reference is made to the contents of Figures 1 and 2, and any redundant description may be omitted.

[0106] In a communication system according to various embodiments of the present disclosure, a web application for providing a service (e.g., a real-time interaction service) may be provided by a data channel application server (DCAS). According to one embodiment, the data channel application server may be located in (e.g., included in) an IMS operator network or a third-party network. In the present disclosure, a web application provided by the data channel application server may be referred to as a data channel application (DCA). According to one embodiment, a terminal participating in a service (e.g., a real-time interaction service) provided by a data channel application may exchange data required by the service directly or through an intermediate node with another terminal participating in the same service using a data channel (DC), and may communicate with the data channel application server using a bootstrap data channel (BDC).

[0107] Referring to FIGS. 3A and 3B , a communication system may include a UE (101) and an IM CN subsystem. According to one embodiment, the UE (101) may communicate with other UEs located in a remote IMS network (260) and components of the IM CN subsystem via the IM CN subsystem. According to one embodiment, the IM CN subsystem may include at least one of a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230), an IMS HSS (240), an IMS AGW (250), a data channel signaling function (310), a media function (321), an NEF (330), a data channel application server (340), or a data channel application repository (350).

[0108] According to one embodiment, the data channel signaling function (310) described above may perform the following functions.

[0109] - Management and control of data channels, including bootstrap data channels.

[0110] - Data channel management and event generation / reception through communication with IMS AS

[0111] - Management and distribution control of data channel applications

[0112] - Communication with 5G network functions (NF) for providing data channel application services.

[0113] - Proxy role for resource distribution of data channel application server (340)

[0114] According to one embodiment, the data application storage (350) described above can store and manage data channel applications and can be located inside or outside the data channel server (340).

[0115] According to one embodiment, the media function (321) or MRF (270) described above may perform the following functions.

[0116] - Management and control of media resources to be transmitted over data channels, including bootstrap data channels.

[0117] - Acts as a proxy for data exchange with the endpoint of the data channel connected to the terminal and other endpoints.

[0118] According to one embodiment, the media function (321) or MRF (270) described above may provide equivalent functions with different interfaces, and in consideration of compatibility with other network equipment and user terminals, only one of the media function (321) or MRF (270) may be included in the data channel server (340), or both may be included together in the data channel server (340).

[0119] FIG. 4 illustrates a network structure including a connection between a core network and an IMS network in a wireless communication system according to embodiments of the present disclosure. Reference is made to FIGS. 1 to 3 , and any redundant description may be omitted.

[0120] In one embodiment, the terminal may send a SIP INVITE message to the P-CSCF to establish an IMS session for making an IMS call. Thereafter, the IMS session may be established through communication between the P-CSCF, S-CSCF, I-CSCF, IMS AS, or HSS, according to the IMS session establishment procedure.

[0121] In one embodiment, if the UE's IMS call is structured to pass through a 5G system (e.g., data is transmitted via a 5G PDU session), the PCF may be responsible for PDU session policy management, including data resource management between the UE, RAN, UPF, or IMS-AGW. To this end, the P-CSCF may provide the PCF with IMS session information necessary for data resource management of the IMS session. At this time, the P-CSCF may act as an AF to the PCF and may use the N5 interface.

[0122] In one embodiment, the PCF may perform terminal policy or session policy management, including determining policy information, including data resource reservation, quality of service (QoS) rule determination, and Policy Control Request Trigger (PCRT) generation, based on IMS session information. Based on IMS session information, the PCF may establish or identify a PDU session associated / corresponding to the corresponding IMS session.

[0123] For example, when a terminal successfully establishes an IMS call, (1) an IMS session is established between IMS nodes, (2) a PDU session is established between 5G CN NFs, and the relationship between (1) the IMS session and (2) the PDU session can be identified by the PCF based on the IMS session information provided to the PCF by the P-CSCF.

[0124] According to one embodiment, if the IMS call of the terminal is structured to pass through a 4G system (e.g., a structure in which data is transmitted through an evolved packet system (EPS) PDN session), the role of the PCF described above may be performed by the PCRF.

[0125] Figure 5 illustrates signal flow for providing an IMS data channel service experience in a wireless communication system according to embodiments of the disclosure. It should be noted that, according to various embodiments, the term "IMS data channel service experience" may be replaced with terms having substantially the same meaning, such as IMS data communication (DC), IMS service, or IMS DC service.

[0126] Referring to FIG. 5, according to one embodiment, UE#1 may be a UE (a multimedia telephony service for IMS (MTSI) UE) that does not support data transmission via an IMS data channel, and may refer to a UE that only supports data transmission via a multimedia telephony (MMTel) session. UE#1 may request an IMS call to transmit a media stream using at least one of audio, video, or text to an IMS network. The IMS network (e.g., IMS AS) may provide an IMS media session (e.g., MMTel session) to UE#1, and transmit and receive the media stream using at least one of audio, video, or text to and from UE#2 via an IMS-AGW through an RTP (real time transport protocol) or RTCP (real time transport control protocol) connection.

[0127] An IMS network may provide the same or similar services as those provided through an IMS data channel to a terminal (e.g., an MTSI UE) that does not support data transmission through an IMS data channel, depending on the user of the service or the subscriber of the service. In this case, the IMS network (e.g., an IMS AS) may verify whether the terminal (e.g., an MTSI UE) is a terminal that can receive the service experience of the IMS data channel, and may establish an IMS DC session (e.g., an IMS DC bootstrap session, an IMS DC application session) at least between the IMS network itself or between the IMS network and the terminal (e.g., a DC MTSI UE) that supports the IMS data channel corresponding to the call party, to transmit and receive control signals. Accordingly, an IMS DC session may be established between a DC AS, NEF, DCSF, IMS AS, MF / MRF (e.g., within an IMS network), or between a DC AS, an IMS network of the counterpart UE (UE#2) (e.g., which may include NEF, DCSF, IMS AS, MF / MRF), and the counterpart UE (UE#2), so that control signals may be transmitted and received.

[0128] According to one embodiment, UE#1 can transmit and receive data of a service provided by a DC service from a DC AS via a data path external to the IMS (e.g., the Internet via a terminal web browser, or SMS). According to one embodiment, UE#2 can transmit and receive data of a service provided by a DC service from a DC AS via at least one of an IMS network on the UE#1 side or an IMS network on the UE#2 side. According to one embodiment, UE#1 can communicate with the DC AS via an IMS external path, and information input / output by UE#1 to / from the DC AS can be delivered to UE#2 via an IMS DC user plane path of the IMS network on the UE#1 side.

[0129] Figures 6a and 6b illustrate further signal flows for providing an IMS data channel service experience in a wireless communication system according to embodiments of the present disclosure. It should be noted that, in various embodiments, the term "IMS data channel service experience" may be replaced with terms having substantially the same meaning, such as "IMS DC," "IMS service," or "IMS DC service."

[0130] Various embodiments of the present disclosure may include at least one of all, some, or a combination of some of the steps disclosed in FIGS. 6A to 6B , and a step may be considered not to be an essential step as long as it produces substantially the same technical effect even if the step is omitted.

[0131] FIGS. 6A and 6B illustrate examples of a method for providing an IMS DC service experience to a terminal that does not support DC in a communication system according to various embodiments of the present disclosure.

[0132] Referring to FIGS. 6a and 6b, the terminal and the network can establish an IMS session and an IMS DC session to utilize the IMS DC service experience through the following procedures.

[0133] In step 0, UE#1 may receive a request from a user to make a call to a service center phone number providing IMS DC services. In one embodiment, the DC AS (application server) providing the IMS DC services may perform the event subscription procedures 0a to 0b below in advance so that the IMS AS can notify the DC AS when a user makes a call to the IMS DC service center phone number.

[0134] In step 0a, the DC AS may provide the DCSF, via the NEF, at least one of: 'information informing the DCSF that it can support interworking to provide DC service experience to MTSI UEs (e.g., UEs that do not support DC) (described as "DC interworking for MTSI" support for convenience, but not limited to this term),' 'a list of user ID(s) (identifier(s)) that support interworking,' 'a list of service ID(s) that support interworking,' or 'DC control information.' The DC AS may request a subscription to be notified when an event related to providing interworking to a service or user included in at least one of the list of user ID(s) that support interworking or the list of service ID(s) that support interworking occurs. In one embodiment, the DCSF may provide the information(s) received from the DC AS via the NEF to the HSS / UDM or to the IMS AS. DCSF may request to be notified when an event related to the provision of interworking occurs for a service or user included in at least one of the lists of user ID(s) that support interworking or the lists of service ID(s) that support interworking.

[0135] In step 0b, the HSS / UDM may provide the IMS AS or S-CSCF with 'information to inform the DCSF whether it can support interworking to provide DC service experience to MTSI UEs (e.g., UEs that do not support DC)' if there is a request for at least one of the service profiles for services included in the lists received in step 0a or user subscriber information for users included in the lists during the IMS registration procedure.

[0136] In step 1, UE#1 may send a SIP INVITE request to the IMS AS via the P-CSCF and S-CSCF in the originating network. The request sent by UE#1 may include an initial SDP, which may include a request for audio (e.g., an audio call).

[0137] In step 2, the IMS AS can check whether the "DC interworking for MTSI" service profile received in step 0b is applicable to the call request of UE#1 in step 1. For example, the IMS AS can determine that the "DC interworking for MTSI" service profile is applicable based on the called ID (e.g., the phone number of UE#2, i.e., the phone number of the service center) and the calling ID (e.g., the phone number of UE#1) included in the SIP INVITE if the called ID or the calling ID is included in the lists included in steps 0a and 0b. Furthermore, the IMS AS can determine whether the IMS AS can trigger or initiate a 'procedure for providing a DC service experience to UE#1' to the DCSF or DC AS even though UE#1 did not request an IMS DC session.

[0138] In step 3, if the IMS AS determines that it can initiate the 'procedure for providing a DC service experience to UE#1' in step 2, it can search for the DCSF responsible for the DC interworking service. Referring to FIG. 6a, the IMS can request the HSS / UDM for the DCSF ID stored in the subscriber information. For example, the IMS AS can request the DCSF ID responsible for DC interworking, stored in the subscriber information of the current user (UE#1 user), using the SDM Get Request message. In one embodiment, the above-described information may be the information stored in step 0a.

[0139] In step 4, the HSS / UDM may provide at least one of the DCSF ID or DCSF address to the IMS AS as requested in step 3. It should be noted that, in one embodiment, the operations in steps 3 and 4 may be performed by the NRF instead of the HSS / UDM.

[0140] In step 5, the IMS AS may, based on the determination made in step 2, notify the DCSF retrieved in step 4 that an event related to the DC interworking service has occurred. For example, the notification message transmitted by the IMS AS may include at least one of a service ID or a user ID corresponding to the DC interworking service. In one embodiment, the service ID and the user ID may include IDs included in the lists included in step 0a.

[0141] In step 6, DCSF can identify that an event related to the DC interworking service has occurred based on the notification message received in step 5. Accordingly, DCSF can provide the notification message to the NEF to notify the DC AS that requested the subscription.

[0142] In step 7, NEF can forward the message of step 6 to the DC AS.

[0143] In step 8, the DC AS may perform an authentication or authorization procedure to determine at least one of 'whether the DCSF that transmitted the message in steps 6 and 7 is a DCSF that is permitted to receive information provided by the DC AS' or 'whether the user corresponding to the user ID provided by the DCSF is a user permitted to receive information provided by the DC AS'.

[0144] In step 9, after the authentication or authorization procedure of step 8 is successfully performed, the DC AS may provide information related to the DC interworking service. The AF may provide the information related to the DC interworking service and request that at least one of the DCSF, the IMS AS, or UE#1 provide the information. In one embodiment, the information related to the DC interworking service may include service address information that allows a user to access the DC service even if UE#1 is a terminal that does not support DC calls. In one embodiment, the service address information may be an http link.

[0145] In step 10, the NEF may forward the information related to the DC interworking service received in step 9 to the DCSF and request it to provide it to the IMS AS and / or UE#1.

[0146] In step 11, the DCSF may forward the information related to the DC interworking service received in step 10 to the IMS AS and request it to be provided to UE#1.

[0147] In step 12, if the DCSF receives 'information related to DC interworking service' or 'a request to provide such information to the terminal or IMS AS' in step 10, the DCSF may determine whether to establish an IMS DC session to the called party based on the information(s) received in step 0a. For example, if the DC control information in step 0a includes a request for a DC interworking service and 'information indicating that a general IMS session can be provided to a party that does not support DC, and both an IMS session and an IMS DC session can be provided to a party that supports DC', the DCSF may determine to establish an IMS DC session only to the called party (UE#2). At this time, whether the called party supports IMS DC may be determined based on at least one of the called party user ID, the service profile applied in step 2, the list(s) provided in steps 0a to 0b, or the DC control information.

[0148] In step 13, if it is decided to establish an IMS DC session for the called party in step 12, the DCSF may determine a DC control policy, including generating DC media information required for allocating MDC1 or MDC2 resources to the MF or MRF for the called party. In one embodiment, based on the above-described policy, the MF or MRF may allocate MDC1 or MDC2 resources.

[0149] In step 14, the IMS AS may provide the SIP INVITE message of step 1 to the called UE through the S-CSCF and the I-CSCF. At this time, the SIP INVITE may additionally include an SDP offer requesting a DC bootstrap session to support DC interworking. The SDP offer requesting a DC bootstrap session to support DC interworking may be provided when the IMS AS identifies that an IMS DC session can be established on the called UE based on the procedures of steps 11 to 13. For example, if the IMS AS receives a 'request to transfer media resource allocation information based on DC control policy to MF or MRF' from the DCSF in step 13, or a 'request to provide service data for DC interworking' from the DCSF in step 11, the IMS AS may determine that an IMS DC session can be established on the called UE and may propose this to the called UE.

[0150] In step 15, the SIP INVITE can be delivered to UE#2 through the called party's I-CSCF, S-CSCF, and P-CSCF.

[0151] At step 16, SDP negotiation (e.g., audio call or IMS DC session setup) for the called network and UE#2 may be performed.

[0152] Below, steps 17 to 28 according to the above-described steps are illustrated with reference to FIG. 6b.

[0153] In step 17, UE#2 and the called network may provide an 18X response to the calling network, including an SDP answer for the bootstrap DC. Based on the SDP answer, the MF or MRF may update the data channel media resource information for UE#2.

[0154] In step 18, UE#2 may return a 200 OK response to the I-CSCF and S-CSCF of the originating network.

[0155] In step 19, the 200 OK response from step 15 can be forwarded to IMS-AS.

[0156] In step 20, the IMS AS may send a notification to the DCSF regarding a successful session establishment event. The notification sent by the IMS AS may be conveyed using the Nimsas_SessionEventControl Notify message, which may include at least one of a SessionEstablishmentSuccessEvent, a Session ID, or a Media Info List.

[0157] At step 21, DCSF may respond to the Nimsas notification request.

[0158] In step 22, a 200 OK message may be transmitted to UE#1, which may include a response to the audio call of step 1. In one embodiment, information related to a DC interworking service may also be transmitted based on the request message of step 11. The information related to the DC interworking service may include 'service address information that allows a user to access the DC service even though UE#1 is a terminal that does not support DC calls.' In one embodiment, the service address information may be an http link.

[0159] At step 23, UE#1 can proceed with an audio call with UE#2.

[0160] In step 24, UE#1 can access a service server (e.g., a DC AS) through application layer operations, without going through the IMS network, based on the service address information received in step 22. For example, UE#1 can provide the user with an audio phone call connection to the service center, while simultaneously indicating on the user display that the service server can be accessed through a web browser. The user can access a web page provided by the service center using the address. In one embodiment, the web page can provide a service (e.g., a customer guidance service using an avatar) that the service provider intended to provide through the app by installing a separate app on UE#1 through the IMS DC session. Accordingly, the user can use a service similar to the IMS DC service using a terminal that does not support the IMS DC session.

[0161] In step 25, UE#2, IMS AS, DCSF, MF / MRF, and DC AS may establish an IMS DC bootstrap session. In one embodiment, DC1, DC2, and MDC3 resources may be allocated and interfaces may be connected.

[0162] In step 26, UE#2 may download the DC application via an IMS DC bootstrap session. In one embodiment, an IMS DC application session may then be established.

[0163] In step 27, UE#2 can identify and process the DC application data received through the DC AS or MF and the audio data received from UE#1 in step 23 as data that are related to each other. According to one embodiment, UE#2 can obtain or determine information about the relationship between the audio data and the DC application based on the SIP INVITE message in step 15 and the data received from the DC AS in step 26.

[0164] In step 28, UE#1 may perform input or output of information to a service server (DC AS) through an application layer while making an audio call with UE#2. According to one embodiment, the input / output information of UE#1 existing in the DC AS may be provided to UE#2 as IMS DC application data from at least one of DCSF, MF, or MRF through an MDC2 or Mb interface.

[0165] Figures 7a and 7b illustrate further signal flows for providing an IMS data channel service experience in a wireless communication system according to embodiments of the present disclosure. It should be noted that, in various embodiments, the term "IMS data channel service experience" may be replaced with terms having substantially the same meaning, such as "IMS DC," "IMS service," or "IMS DC service."

[0166] Various embodiments of the present disclosure may include at least one of all, some, or a combination of some of the steps disclosed in FIGS. 7A to 7B , and a step may be considered not to be an essential step as long as it produces substantially the same technical effect even if the step is omitted.

[0167] FIGS. 7A and 7B illustrate another example of a method for providing an IMS DC service experience to a terminal that does not support DC in a communication system according to various embodiments of the present disclosure.

[0168] Referring to FIGS. 7a and 7b, the terminal and the network can establish an IMS session and an IMS DC session to utilize the IMS DC service experience through the following procedures.

[0169] In step 0, UE#1 may receive a request from a user to make a call to a service center phone number providing IMS DC services. In one embodiment, the DC AS providing the IMS DC services may perform the event subscription procedures 0a to 0b below in advance so that the IMS AS can notify the DC AS when a user makes a call to the IMS DC service center phone number.

[0170] In step 0a, the DC AS may provide the DCSF with at least one of: 'information informing the DCSF that it can support interworking to provide DC service experience to MTSI UEs (e.g., UEs that do not support DC) via NEF (described as "DC interworking for MTSI" support for convenience, but not limited to this term),' 'a list of user ID(s) that support interworking,' 'a list of service ID(s) that support interworking,' or 'DC control information.' The DC AS may request a subscription to be notified when an event related to providing interworking to a service or user included in at least one of the list of user ID(s) that support interworking or the list of service ID(s) that support interworking occurs. In one embodiment, the DCSF may provide the information(s) received from the DC AS via NEF to the HSS / UDM or to the IMS AS. DCSF may request to be notified when an event related to the provision of interworking occurs for a service or user included in at least one of the list of user ID(s) supporting interworking or the list of service ID(s) supporting interworking.

[0171] In step 0b, the HSS / UDM may provide the requesting IMS AS or S-CSCF with 'information indicating whether the DCSF can support interworking to provide DC service experience to MTSI UEs (e.g., UEs that do not support DC)', if there is a request for at least one of the service profiles for the services included in the lists received in step 0a during the IMS registration procedure or the user subscriber information for the users included in the lists.

[0172] In step 1, UE#1 may send a SIP INVITE request to the IMS AS via the P-CSCF and S-CSCF in the originating network. The request sent by UE#1 may include an initial SDP, which may include a request for audio (e.g., an audio call).

[0173] In step 2, the IMS AS can check whether the "DC interworking for MTSI" service profile received in step 0b is applicable to the call request of UE#1 in step 1. For example, the IMS AS can determine that the "DC interworking for MTSI" service profile is applicable based on the called ID (e.g., the phone number of UE#2, i.e., the phone number of the service center) and the calling ID (e.g., the phone number of UE#1) included in the SIP INVITE if the called ID or the calling ID is included in the lists included in steps 0a and 0b. Furthermore, the IMS AS can determine whether the IMS AS can trigger, initiate a 'procedure for providing a DC service experience to UE#1' to the DCSF or the DC AS even though the UE#1 did not request an IMS DC session.

[0174] In step 3, if the IMS AS determines that it can initiate the 'procedure for providing a DC service experience to UE#1' in step 2, it can search for the DCSF responsible for the DC interworking service. Referring to FIG. 7a, the IMS can request the HSS / UDM for the DCSF ID stored in the subscriber information. For example, the IMS AS can request the DCSF ID responsible for DC interworking stored in the subscriber information of the current user (user UE#1) using the SDM Get Request message. In one embodiment, the above-described information may be the information stored in step 0a.

[0175] In step 4, the HSS / UDM may provide the IMS AS with at least one of the DCSF ID or the DCSF address, as requested in step 3. In one embodiment, the operations in steps 3 and 4 may also be performed by the NRF instead of the HSS / UDM.

[0176] In step 5, the IMS AS may, based on the determination made in step 2, notify the DCSF retrieved in step 4 that an event related to the DC interworking service has occurred. For example, the notification message transmitted by the IMS AS may include at least one of a service ID or a user ID corresponding to the DC interworking service. In one embodiment, the service ID and the user ID may include IDs included in the lists included in step 0a.

[0177] In step 6, DCSF can identify that an event related to the DC interworking service has occurred based on the notification message received in step 5. Accordingly, DCSF can provide the notification message to the NEF to notify the DC AS that requested the subscription.

[0178] In step 7, NEF can forward the message of step 6 to the DC AS.

[0179] In step 8, the DC AS may perform an authentication or authorization procedure to determine at least one of 'whether the DCSF that transmitted the message in steps 6 and 7 is a DCSF that is permitted to receive information provided by the DC AS' or 'whether the user corresponding to the user ID provided by the DCSF is a user permitted to receive information provided by the DC AS'.

[0180] In step 9, if the DCSF receives a notification of an event related to the DC interworking service in step 5, the DCSF may determine whether to establish an IMS DC session to the called party based on the information(s) received in step 0a. For example, if the DC control information in step 0a includes a request for the DC interworking service and includes information indicating that 'a general IMS session can be provided to a party that does not support DC, and both an IMS session and an IMS DC session can be provided to a party that supports DC,' the DCSF may determine to establish an IMS DC session only to the called party (UE#2). At this time, whether the called party supports IMS DC may be determined based on at least one of the called party user ID, the service profile applied in step 2, the list(s) provided in steps 0a to 0b, or the DC control information.

[0181] In step 10, if it is decided to establish an IMS DC session for the called party in step 9, the DCSF may determine a DC control policy, including generating DC media information required for allocating MDC1 or MDC2 resources to the MF or MRF for the called party. In one embodiment, based on the above-described policy, the MF or MRF may allocate MDC1 or MDC2 resources.

[0182] In step 11, the IMS AS may provide the SIP INVITE message of step 1 to the called UE through the S-CSCF and I-CSCF. At this time, the SIP INVITE may additionally include an SDP offer requesting a DC bootstrap session to support DC interworking. The SDP offer requesting a DC bootstrap session to support DC interworking may be provided when the IMS AS identifies that an IMS DC session can be established on the called UE based on the procedures of steps 9 and 10. For example, if the IMS AS receives a request from the DCSF in step 10 to 'transmit media resource allocation information based on DC control policy to the MF or MRF', or determines that the DC interworking service profile can be applied in step 2, or learns of the existence of the DCSF for applying the DC interworking service profile in steps 3 and 4, the IMS AS can determine that an IMS DC session can be established on the called side and can propose this to the called side terminal.

[0183] In step 12, the SIP INVITE can be delivered to UE#2 through the called party's I-CSCF, S-CSCF, and P-CSCF.

[0184] At step 13, SDP negotiation (e.g., audio call or IMS DC session setup) for the called network and UE#2 may be performed.

[0185] Below, steps 14 to 29 according to the above-described steps are illustrated with reference to FIG. 7b.

[0186] In step 14, UE#2 and the called network may provide an 18X response to the calling network, including an SDP answer for the bootstrap DC. Based on the SDP answer, the MF or MRF may update the data channel media resource information for UE#2.

[0187] In step 15, UE#2 may return a 200 OK response to the I-CSCF and S-CSCF of the originating network.

[0188] In step 16, the 200 OK response from step 15 can be forwarded to IMS-AS.

[0189] In step 17, the IMS AS may send a notification to the DCSF regarding a successful session establishment event. The notification sent by the IMS AS may be conveyed using the Nimsas_SessionEventControl Notify message, which may include at least one of a SessionEstablishmentSuccessEvent, a Session ID, or a Media Info List.

[0190] At step 18, DCSF may respond to the Nimsas notification request.

[0191] In step 19, a 200 OK message may be sent to UE#1, which may include a response to the audio call in step 1.

[0192] At step 20, UE#1 can proceed with an audio call with UE#2.

[0193] In step 21, the IMS AS can determine that a session supporting DC interworking is established if the procedures of steps 16 to 18 are performed (e.g., if an IMS session for UE#1 is established), and can identify whether UE#1 is ready to access the DC AS via the application layer. Accordingly, the IMS AS can send a notification message to the DC AS to trigger or initiate the provision of service address information to UE#1. The IMS AS can send the notification message to the DCSF, and the message can include information notifying that a session for DC interworking has been set up (e.g., at least one of "DC interworking Session Setup" or a user ID). In order to send this notification message, a subscription procedure that sets up a session for DC interworking as an event can be performed in advance (e.g., steps 0a to 0b).

[0194] At step 22, DCSF may forward the notification message of step 21 to NEF.

[0195] At step 23, the NEF may forward the notification message of step 22 to the DC AS.

[0196] In step 24, the DC AS may provide information related to the DC interworking service to UE#1 via an SMS message. The information related to the DC interworking service provided by the DC AS may include service address information that allows the user to access the DC service even if UE#1 is a terminal that does not support DC calls. In one embodiment, the service address information may be an HTTP link.

[0197] In step 25, UE#1 can access a service server (e.g., DC AS) through application layer operation without going through the IMS network based on the service address information received in step 24. For example, UE#1 can provide the user with an audio phone call connection to the service center, and at the same time, display on the user display that the service server can be accessed through a web browser. The user can access a web page provided by the service center using the address. In one embodiment, the web page can provide a service (e.g., a customer guidance service using an avatar) that the service provider intended to provide through the app by installing a separate app on UE#1 through the IMS DC session. Accordingly, the user can use a service similar to the IMS DC service using a terminal that does not support the IMS DC session.

[0198] In step 26, UE#2, IMS AS, DCSF, MF / MRF, and DC AS may establish an IMS DC bootstrap session. In one embodiment, DC1, DC2, and MDC3 resources may be allocated and interfaces may be connected.

[0199] In step 27, UE#2 may download the DC application via an IMS DC bootstrap session. In one embodiment, an IMS DC application session may then be established.

[0200] In step 28, UE#2 can identify and process the DC application data received through the DC AS or MF and the audio data received from UE#1 in step 20 as data related to each other. According to one embodiment, UE#2 can obtain or determine information about the relationship between the audio data and the DC application based on the SIP INVITE message in step 12 and the data received from the DC AS in step 27.

[0201] In step 29, UE#1 may perform input or output of information to a service server (DC AS) through the application layer while making an audio call with UE#2. According to one embodiment, input and output information of UE#1 existing in the DC AS may be provided to UE#2 as IMS DC application data from at least one of DCSF, MF, or MRF through the MDC2 or Mb interface.

[0202] In order to perform the above-described embodiments of the present invention, a transmitter, a receiver, and a processor of a terminal and a base station are respectively illustrated in FIGS. 8 and 9. In the above-described embodiments, a method for a terminal to perform positioning in a sidelink is described, and to perform this, the receiver, the processor, or the transmitter of the base station and the terminal can each operate according to the embodiment.

[0203] FIG. 8 illustrates the configuration of a terminal according to various embodiments of the present disclosure. Specifically, FIG. 8 illustrates the internal structure of a terminal according to an embodiment of the present invention.

[0204] As illustrated in FIG. 8, the terminal may include a receiver (800), a transmitter (804), a processor (802) (or a controller) or a memory (not illustrated). The terminal receiver (800) and the terminal transmitter (804) may be collectively referred to as a transceiver in the embodiment of the present invention. The transceiver of the terminal may be used to transmit and receive signals with a base station. Here, the signals may include control information and data. To this end, the transceiver may be configured with an RF (radio frequency) transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and down-converts the frequency of a received signal. In addition, the transceiver may receive a signal through a wireless channel and output it to the terminal processor (802), and transmit the signal output from the terminal processor (802) through the wireless channel. The terminal processor (802) may control a series of processes so that the terminal may operate according to the embodiments of the present invention described above.

[0205] FIG. 9 illustrates the configuration of a base station according to various embodiments of the present disclosure. More specifically, FIG. 9 illustrates the internal structure of a base station according to an embodiment of the present disclosure.

[0206] As illustrated in FIG. 9, the base station may include a receiver (901), a transmitter (905), a processor (903) (or a controller), or a memory (not illustrated). The base station receiver (901) and the base station transmitter (905) may be collectively referred to as a transceiver in the embodiment of the present invention. The transceiver of the base station may be used to transmit and receive signals with a terminal. Here, the signals may include control information and data. To this end, the transceiver may be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and frequency-down-converts the received signal. In addition, the transceiver may receive a signal through a wireless channel and output it to the base station processor (903), and transmit the signal output from the base station processor (903) through the wireless channel. The base station processor (903) may control a series of processes so that the base station can operate according to the embodiments of the present invention described above.

[0207] Meanwhile, the embodiments of the present invention disclosed in this specification and drawings are merely specific examples to easily explain the technical content of the present invention and assist in understanding the present invention, and are not intended to limit the scope of the present invention. In other words, it will be apparent to those skilled in the art that other modifications based on the technical concept of the present invention are possible. Furthermore, each embodiment can be combined and operated as needed. For example, all embodiments of the present invention can be operated as a base station and a terminal by combining parts thereof.

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

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

[0210] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0211] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

[0212] Meanwhile, the order of description in the drawings explaining the method of the present invention does not necessarily correspond to the order of execution, and the order of precedence may be changed or executed in parallel.

[0213] Alternatively, the drawings illustrating the method of the present invention may omit some components and include only some components within a scope that does not harm the essence of the present invention.

[0214] In addition, the method of the present invention may be implemented by combining some or all of the contents included in each embodiment within a scope that does not harm the essence of the invention.

[0215] Various embodiments of the present disclosure have been described above. The above description of the present disclosure is for illustrative purposes only, and the embodiments of the present disclosure are not limited to the disclosed embodiments. Those skilled in the art will appreciate that the present disclosure can be easily modified into other specific forms without altering the technical spirit or essential characteristics of the present disclosure. The scope of the present disclosure is indicated by the claims below rather than the detailed description described above, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included within the scope of the present disclosure.

[0216] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0217] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. For example, some or all of the embodiments may be combined with some or all of one or more other embodiments, and such combinations should naturally fall within the scope of the embodiments proposed in this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be determined not only by the scope of the claims described below, but also by equivalents thereof.

[0218] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

[0219] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples to easily explain the technical contents of the present disclosure and to help the understanding of the present disclosure, and are not intended to limit the scope of the present disclosure. In other words, it will be apparent to those skilled in the art that other modified examples based on the technical idea of ​​the present disclosure are possible. In addition, each of the above embodiments can be combined and operated with each other as needed. For example, parts of one embodiment of the present disclosure and another embodiment can be combined with each other to operate a base station and a terminal. In addition, other modified examples based on the technical idea of ​​the above embodiments can be implemented in various systems such as an FDD LTE system, a TDD LTE system, a 5G or NR system, etc.

Claims

1. In a mobile communication system, a method performed by a DC (data channel) AS (application server) entity is as follows: A step of transmitting a first message to an IMS (IP (internet protocol) multimedia subsystem) AS (application server) entity for subscribing to an event related to DC interworking of an MTSI (multimedia telephony service for IMS) UE (user equipment); A step of receiving a second message from the IMS AS entity for notifying the DC interworking to the DC MTSI UE; and A method comprising the step of transmitting, to the MTSI UE, information for accessing the DC AS.

2. In claim 1, The first message includes user IDs associated with the DC MTSI UE, A method wherein the second message includes a user ID associated with a DC MTSI UE corresponding to DC interworking of the MTSI UE among user IDs associated with the DC MTSI UE.

3. In claim 1, The above first message is transmitted via a network exposure function (NEF) entity, and The second message is received via the NEF entity.

4. In claim 1, Information for accessing the above DC AS is transmitted to the MTSI UE through the IMS AS entity.

5. In a mobile communication system, a method performed by an IMS (IP (internet protocol) multimedia subsystem) AS (application server) entity, A step of receiving a first message from a DC(data channel) AS(application server) entity for subscribing to an event related to DC interworking of an MTSI(multimedia telephony service for IMS) UE(user equipment); A step of identifying the occurrence of the event based on the INVITE information received from the MTSI UE; and A method comprising the step of transmitting a second message to the DC AS entity for notifying the DC interworking for the DC MTSI UE.

6. In claim 5, The first message includes user IDs associated with the DC MTSI UE, A method wherein the second message includes a user ID associated with a DC MTSI UE corresponding to DC interworking of the MTSI UE among user IDs associated with the DC MTSI UE.

7. In claim 5, The above first message is received via a network exposure function (NEF) entity, and The second message is transmitted via the NEF entity.

8. In claim 5, the method comprises: A step of receiving a third message including information for connecting to the DC AS from the DC AS entity; and A method comprising the step of transmitting, to the MTSI UE, a fourth message including information for accessing the DC AS.

9. In a mobile communication system, a DC (data channel) AS (application server) entity, Transceiver; and Including a controller coupled with the above transceiver, The above controller, Transmits a first message to an IMS (IP (internet protocol) multimedia subsystem) AS (application server) entity to subscribe to an event related to DC interworking of an MTSI (multimedia telephony service for IMS) UE (user equipment), Receive a second message from the IMS AS entity for notifying the DC interworking to the DC MTSI UE, and A DC AS entity configured to transmit information for connecting to the DC AS to the MTSI UE.

10. In claim 9, The first message includes user IDs associated with the DC MTSI UE, The second message is a DC AS entity including a user ID associated with a DC MTSI UE corresponding to DC interworking of the MTSI UE among the user IDs associated with the DC MTSI UE.

11. In claim 9, The above first message is transmitted via a network exposure function (NEF) entity, and The second message is received by the DC AS entity via the NEF entity.

12. In claim 9, Information for connecting to the above DC AS is transmitted to the MTSI UE through the IMS AS entity.

13. In a mobile communication system, an IMS (IP (internet protocol) multimedia subsystem) AS (application server) entity, Transceiver; and Including a controller coupled with the above transceiver, The above controller, Receive a first message from a DC(data channel) AS(application server) entity to subscribe to an event related to DC interworking of an MTSI(multimedia telephony service for IMS) UE(user equipment), Based on the INVITE information received from the above MTSI UE, identify the occurrence of the above event, and An IMS AS entity configured to transmit a second message to the DC AS entity for notifying the DC interworking for the DC MTSI UE.

14. In claim 13, The first message includes user IDs associated with the DC MTSI UE, The second message is an IMS AS entity that includes a user ID associated with a DC MTSI UE corresponding to DC interworking of the MTSI UE among the user IDs associated with the DC MTSI UE.

15. In claim 13, The above first message is received via a network exposure function (NEF) entity, and The second message is an IMS AS entity transmitted via the NEF entity.

Images