Method and device for displaying user-related information in IMS service

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. A method performed by a first Internet protocol multimedia core network subsystem (IMS) application server (AS) in a wireless communication system according to an embodiment of the present disclosure may comprise the steps of: receiving a first session initiation protocol (SIP) INVITE message including third party identification information from a first user equipment (UE); confirming rich call data (RCD)-related information from a home subscriber server (HSS) in response to the first SIP INVITE message; and receiving, from the HSS, address information of an RCD server included in the RCD-related information.

Description

Method and device for displaying user-related information in IMS services

[0001] The present disclosure relates to an IMS (IP (internet protocol) Multimedia Core Network Subsystem) service, and more particularly, to a method and device for displaying user-related information provided by a third-party service.

[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] The IMS system is a system for transmitting IP-based multimedia, and various services such as VoLTE (voice over LTE (long term evolution)) and VoNR (voice over NR (new radio)) can be provided through the existing IMS network linked to the LTE or 5G network. The IMS data channel can provide various additional services such as user location information transmission and screen sharing using separate applications in the basic voice or video-based service by using the data channel linked to IMS, i.e. IMS-DC (data communication) service, in addition to the existing RTP (real time transport protocol)-based voice, video, and text services. In order to transmit additional services using the data channel in the IMS data network, the terminal transmits signaling information for the data channel-based service to the network through the bootstrap data channel connection process. The network transmits application information to the terminal based on the settings of the user or service provider and the request information received from the terminal, and transmits information so that the terminal can download the application for a specific service. The terminal can request and receive the application based on the information. Additionally, the network may perform media resource management service operations that allocate separate media function entities within the network to receive data for the application and connect them with data channel application servers.

[0009] The present disclosure provides a method and device for providing terminal user-related display information provided by a third-party service to an IMS call service counterpart terminal when an IMS call service is initiated.

[0010] A method of a first network entity according to an embodiment of the present disclosure may include, when starting an IMS (internet protocol multimedia core network subsystem) call service, receiving IMS service request information including information related to the first terminal and information related to the second terminal from a first terminal, requesting third-party service provider information related to the first terminal from a second network entity based on the information related to the first terminal and the information related to the second terminal and receiving the third-party service provider information in response to the request, receiving third-party service-related information from the first terminal and verifying the third-party service-related information, requesting user-related display information of the first terminal from a third-party service provider server based on the third-party service provider information and the information related to the first terminal and receiving user-related display information of the first terminal in response to the request, and transmitting a message including the user-related display information of the first terminal to the second terminal through a counterpart network entity.

[0011] According to an embodiment of the present disclosure, a first network entity includes a transceiver; and a control unit, wherein the control unit, when starting an IMS (internet protocol multimedia core network subsystem) call service, receives IMS service request information including information related to the first terminal and information related to a second terminal from a first terminal, requests third-party service provider information related to the first terminal from a second network entity based on the information related to the first terminal and the information related to the second terminal, receives the third-party service provider information in response to the request, receives third-party service-related information from the first terminal and verifies the third-party service-related information, requests user-related display information of the first terminal from a third-party service provider server based on the third-party service provider information and the information related to the first terminal, receives user-related display information of the first terminal in response to the request, and controls transmission of a message including the user-related display information of the first terminal to the second terminal through a counterpart network entity.

[0012] A method of a first IMS (internet protocol multimedia core network subsystem) AS (application server) according to an embodiment of the present disclosure may include a process of receiving a first SIP (session initiation protocol) invite message including third party identification information from a first UE (user equipment), a process of confirming RCD (rich call data) related information from an HSS (home subscriber server) in response to the first SIP invite message, and a process of receiving, from the HSS, address information of an RCD server included in the RCD related information.

[0013] In accordance with an embodiment of the present disclosure, a first IMS (internet protocol multimedia core network subsystem) AS (application server) entity includes a transceiver; a memory; and at least one processor, wherein the at least one processor may include features for receiving a first SIP (session initiation protocol) invite message including third party identification information from a first UE (user equipment), confirming RCD (rich call data) related information from an HSS (home subscriber server) entity in response to the first SIP invite message, and receiving, from the HSS entity, address information of an RCD server included in the RCD related information.

[0014] A method and device according to one embodiment of the present disclosure can perform operations for generating user-related information (e.g., RCD) of a terminal and transmitting user-related information of a terminal using a caller authentication system by using a third-party service that provides user-related information of a terminal in an IMS service including an IMS call service.

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

[0016] FIG. 2 is an example of a structure for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting user (sender) related information of a terminal using a sender authentication system.

[0017] FIG. 3 is a flowchart illustrating a method for a third-party service provider providing user (caller) related information of a terminal to store specific user-related service-related information in user-related subscription data within an HSS according to one embodiment of the present disclosure.

[0018] FIG. 4 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0019] FIG. 5 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0020] FIG. 6A and FIG. 6B are flowcharts illustrating operations for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user (sender) related information of the terminal using a sender authentication system.

[0021] FIG. 7 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0022] Figure 8 is a device diagram of a terminal according to one embodiment of the present disclosure.

[0023] FIG. 9 is a device diagram of a network entity according to one embodiment of the present disclosure.

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

[0025] In describing this disclosure, descriptions of technical details that are well-known in the technical field to which this disclosure pertains and are not directly related to this disclosure will be omitted. This is to avoid obscuring the gist of this disclosure by omitting unnecessary explanations and to convey it more clearly. Furthermore, the terms described below are defined based on their functions in this disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the contents of this specification as a whole.

[0026] 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.

[0027] Hereinafter, a base station (BS) is an entity that performs resource allocation of a terminal, and may be at least one of a gNode B, an eNode B, a Node B (or an xNode B (where x is an alphabet including g or e)), a wireless access unit, a base station controller, a satellite, an airborn, or a node on a network. A user equipment (UE) may include a mobile station (MS), a vehicle, a satellite, an airborn, a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, a downlink (DL) is a wireless transmission path of a signal transmitted from a base station to a terminal, and an uplink (UL) is a wireless transmission path of a signal transmitted from a terminal to an air station. Additionally, a sidelink (SL) may exist, which means a wireless transmission path of a signal transmitted from a terminal to another terminal.

[0028] In addition, although 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, this may include 5G-Advance or NR-Advance, or 6th generation mobile communication technology (6G) developed after 5G mobile communication technology (or new radio, NR), and the 5G described below may also include existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems with some modifications within a range that does not significantly deviate from the scope of the present disclosure, as determined by a person having skilled technical knowledge.

[0029] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings 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 flowchart 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 flowchart 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).

[0030] 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.

[0031] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.

[0032] 3GPP, responsible for cellular mobile communications standards, is currently standardizing a new core network architecture called 5GC (5G Core) to facilitate the evolution of 4G LTE systems to 5G systems. Compared to the Evolved Packet Core (EPC), the network core for 4G, 5GC supports the following differentiated features:

[0033] 5GC introduces the Network Slice feature. As a requirement of 5G, 5GC must support a variety of terminal types and services. For example, 5GC can support 5G services such as enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC). Each of these terminals and services has different requirements for the core network. For example, eMBB services may require high data rates, while URLLC services may require high reliability and low latency. To meet these diverse service requirements, Network Slice technology has been proposed.

[0034] Network slicing can refer to a method of virtualizing a single physical network to create multiple logical networks (e.g., network slices). An activated network slice can be called a network slice instance (NSI), and each NSI can have different characteristics. By configuring a network function (NF) for each NSI according to its characteristics, mobile carriers can satisfy various service requirements for different terminals / services. For example, mobile carriers 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.

[0035] 5GC can easily support the network virtualization paradigm by separating the mobility management function from the session management function. In 4G LTE, all terminals can 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. In 5G, the number of terminals (including MTC terminals) will explode, and the mobility and traffic / session characteristics that must be supported depending on the terminal type will become more specialized. Therefore, supporting all functions from a single entity (such as the MME) will inevitably reduce scalability by adding entities for each required function. Therefore, various functions are being developed based on a structure that separates the mobility management function from the session management function to improve scalability in terms of the functional / implementation complexity and signaling load of the core entity responsible for the control plane.

[0036] FIG. 1 is a diagram illustrating the network structure and interface of a 5G system according to one embodiment of the present disclosure. Network entities included in the network structure of the 5G system of FIG. 1 may include network functions (NFs) depending on the system implementation.

[0037] Referring to FIG. 1, the network structure of a 5G system may include various network entities. For example, the 5G system may include an authentication server function (AUSF) entity (108), an 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 (EDS). It may include a domain repository (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 equipment (UE) (101).

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

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

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

[0041] DN (110) refers to, for example, an operator service, Internet access, or a third-party service. DN (110) transmits a downlink protocol data unit (PDU) to the UPF entity (104) or receives a PDU transmitted from the UE (101) from the UPF entity (104).

[0042] The PCF entity (106) receives information about packet flows from the application server and provides a function to determine 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 operations, providing policy rules so that control plane function entity(ies) (e.g., AMF entity, SMF entity, 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).

[0043] The SMF entity (105) provides a session management function, and when the UE (101) has multiple sessions, each session can be managed by a different SMF entity. Specifically, the SMF entity (105) is responsible for session management (e.g., session establishment, modification, and termination, including tunnel maintenance between the UPF entity (104) and the (R)AN (102) node), UE IP address allocation and management (optionally including authentication), selection and control of UP functions, setting up traffic steering to route traffic from the UPF entity (104) to the appropriate destination, termination of the interface to policy control functions, enforcement of the control portion of policy and quality of service (QoS), lawful intercept (for SM events and interfaces to the LI system), termination of the session management (SM) portion of NAS messages, downlink data notification, initiation of AN (access network) specific SM information (delivered to the (R)AN (102) via N2 via the AMF entity (103)), determination of the session and service continuity (SSC) mode of the session, and roaming. Supports functions such as functions, etc. Some or all functions of an SMF entity (105) can be supported within a single instance of an SMF entity.

[0044] 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).

[0045] The FE (front end) includes the UDM FE, which is responsible for location management, subscription management, and credential processing, and the PCF entity, which is responsible for policy control. The UDR stores the data required for the functions provided by the UDM-FE and the policy profiles required by the PCF entity. The data stored in the UDR includes 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 accesses the subscription information stored in the UDR and supports functions such as authentication credential processing, user identification handling, access authentication, registration / mobility management, subscription management, and SMS management.

[0046] The UPF entity (104) forwards the downlink PDU received from the DN (110) to the UE (101) via the (R)AN (102), and forwards the uplink PDU received from the UE (101) via the (R)AN (102) to the DN (110). 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 the Data Network, a user plane part 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) to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering and downlink data notification triggering. Some or all of the functions of a UPF entity (104) may be supported within a single instance of a UPF.

[0047] The AF entity (107) interacts with the 3GPP core network to provide services (e.g., supporting functions such as application impact on traffic routing, access to network capability exposure, and interaction with the policy framework for policy control).

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

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

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

[0051] The NEF (111) provides a means to securely expose services and capabilities provided by 3GPP network functions, for example, for third parties, internal exposure / re-exposure, application functions, and edge computing. The NEF (111) receives information from other NF (s) (based on the exposed capability(s) of other NF (s)). The 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.

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

[0053] 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.

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

[0055] 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.

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

[0057] 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0070] - N14: Reference point between two AMFs (103)

[0071] - N15: Reference point between PCF and AMF in non-roaming scenario, reference point between PCF and AMF in visited network in roaming scenario.

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

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

[0074] FIG. 2 is an example of a structure for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting user (sender) related information of the terminal using a sender authentication system.

[0075] In the above structure, the terminal can send a SIP (session initiation protocol) INVITE message to an existing CSCF, such as a P-CSCF (proxy - call session control function) and an S-CSCF (serving - call session control function), to request a call session connection. The SIP INVITE message includes IMPU (IMS public user identity), IMPI (IP multimedia private identity), Calling ID, Caller ID, IMSI (international mobile subscriber identity), and a third-party service provider ID (3). rd The information may be transmitted to the network including at least one terminal (UE #1) related information among the IMPU, IMPI, Called ID, Callee ID, and IMSI and at least one service counterpart terminal (UE #2) related information among the IMPU, IMPI, Called ID, Callee ID, and IMSI.

[0076] The S-CSCF, which receives a SIP INVITE including the above SDP information, can forward the SDP offer contents to the IMS AS (Telephony AS) if the SIP INVITE contains an SDP offer related to a call service. At this time, the S-CSCF can forward the SDP offer to the IMS AS connected to or supporting the caller authentication system if the caller information authentication function is required according to the policy of the network operator and service provider. The S-CSCF can determine the necessity of whether the caller information authentication function is supported by including caller-related indication information (e.g., RCD (rich call data)) in the SIP INVITE message transmitted from the terminal to request the caller information authentication function, or by using a separate service indicator, etc.

[0077] The IMS AS, which has received an SDP offer message including request information for provision of caller-related indication information using a caller authentication system from the S-CSCF, can first check with the HSS (home subscriber server) whether the terminal (UE#1) or the caller can use caller-related indication information through a third-party service. Alternatively, when the terminal requests a service, the SDP offer message may include caller-related indication information provided by a third-party service or may include caller-related indication information related information (3). rdAn IMS AS that receives a SIP INVITE message including the sender-related indication information (e.g., a party ID) can authenticate the sender information using the sender authentication system provided by a third-party service and encrypt the sender-related indication information in the signing server. The SIP INVITE message including the encrypted sender-related indication information, which has completed the authentication and encryption process of the sender information from the sender system, can be transmitted to the S-CSCF of the other network through the ingress IBCF of the other network via the egress IBCF (interconnection border control functions). The S-CSCF of the other network (terminating) can transmit the SIP INVITE message including the encrypted sender-related indication information to the terminating IMS AS to perform the verification and decryption process of the encrypted sender-related indication information. The terminating IMS AS can receive the decrypted sender information from the verification AS and update the SIP INVITE message based on it. The terminating IMS AS can forward a SIP INVITE message containing caller ID information to the receiving terminal (UE #2) via the terminating S-CSCF. The receiving terminal (UE #2) can display the caller ID information to inform the receiving terminal of which user made the call and for what purpose.

[0078] FIG. 3 is a flowchart illustrating a method for a third-party service provider providing user (caller) related information of a terminal to store specific user-related service-related information in user-related subscription data within an HSS according to one embodiment of the present disclosure.

[0079] Referring to FIG. 3, in step 300a, if a specific terminal user has registered with the IMS network, the HSS may forward an NF registration request including relevant profile information to the NRF via the Nnrf_NFManagement_NFRegister message. The NRF may store HSS profile information including specific terminal user information within the NRF.

[0080] In step 300b, the NRF may store the profile information received from the HSS.

[0081] At step 300c, the HSS may receive a response message to the Nnrf_NFManagement_NFRegister message from the NRF.

[0082] In step 301, a third party service provider server (AF) providing caller-related information may decide to generate an AF request message to store caller information display service information (e.g., External group ID, 3rd party ID repository information (e.g., Server address), specific service parameters (Assistant information for selection of group ID (e.g., time period, location of UE, group category (e.g., work or family), 3rd party ID type (e.g., private))) associated with a specific user (subscriber (IMPU) or group of subscribers (IMPUs)) in the UE subscription information.

[0083] In step 302, the AF may forward to the NEF a Nnef_ServiceParameter_Create or Nnef_ServiceParameter_Update message containing at least one of the above information associated with a particular user (subscriber (IMPU) or group of subscribers (IMPUs)) created in step 301, the caller information display service information.

[0084] In step 303, the NEF may forward an Nnrf_NFDiscovery_Request message to the NRF, including a subscriber (IMPU) or a group of subscribers (IMPUs), to request HSS server information that manages specific user-related Subscription information.

[0085] At step 304, NEF can receive HSS server information that manages specific user-related subscription information through NRF.

[0086] In step 305, the NEF may transmit at least one of the caller information display service information associated with a specific user (subscriber (IMPU) or group of subscribers (IMPUs)) received from the AF to the HSS via an Nhss_ImsSDM_Update request.

[0087] In step 306, the HSS may perform an action of storing the specific user-related caller information display service information received from the NEF in the subscription data or updating the existing subscription data.

[0088] At step 307, the HSS may successfully notify the NEF via an Nhss_ImsSDM_Update response indicating that the specific user-related caller information display service information has been included in the Subscription and stored in the HSS.

[0089] At step 308, the NEF may notify the AF that the specific user-related caller information display service information requested by the AF has been successfully delivered to the HSS based on the update request response information received from the HSS.

[0090] FIG. 4 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0091] Referring to FIG. 4, in step 401, the terminal (UE#1) may transmit a SIP INVITE message to an existing CSCF, such as a P-CSCF (proxy - call session control function) and an S-CSCF (serving - call session control function), to request a call session connection. The SIP INVITE message may include IMPU, IMPI, Calling ID, Caller ID, IMSI, and 3 rdAt least one terminal (UE #1) related information among the third party service IDs and at least one service counterpart terminal (UE #2) related information among the IMPU, IMPI, Called ID, Callee ID, and IMSI may be included. In one embodiment, the terminal (UE #1) may receive multiple third party service IDs associated with user personal information (IMPI) when preset or registered with the network. The third party service IDs may be transmitted together in a call session request message when the user uses a caller ID-based call service. Third party service providers that provide user-related caller ID information may register a third party service ID in the HSS to receive caller ID information provided by each service related to a specific terminal. When the terminal (UE #1) makes a call to the service counterpart terminal (UE #2), if the terminal uses a service based on a phone number saved by the user, the terminal may select one third party service ID based on information about which category (e.g., company, school, family, etc.) the information of the service counterpart terminal (UE #2) is saved in. If the terminal (UE#1) does not store information of the service counterpart terminal (UE#2) or does not store it by specifying a category (e.g., company, school, family, etc.), you can select a 3rd party service ID using the UI or other means to use the caller ID service through the 3rd party service when making a call.

[0092] In step 402, the S-CSCF (S-CSCF#1) that receives the SIP INVITE including the above SDP information checks whether the SIP INVITE includes a call service related SDP offer, and if so, can forward the content of the SDP offer to the IMS AS (Telephony AS) in step 403. At this time, the S-CSCF (S-CSCF#1) can forward the SDP offer to the IMS AS (IMS AS-O) that supports the caller ID information authentication function if the IMS call service requires the caller information authentication function according to the policies of the network operator and service provider. If there is no separate policy or setting, the S-CSCF (S-CSCF#1) can determine whether or not to support the caller ID information authentication function if the SIP INVITE message transmitted from the terminal includes caller-related indication information (e.g., RCD) or the terminal determines the need for supporting the caller information authentication function using a separate service indicator, etc.

[0093] In steps 404 and 405, the IMS AS (IMS AS-O) that receives the SIP INVITE message including the request information for providing caller-related indication information using the caller authentication system from the S-CSCF (S-CSCF#1) can first check with the HSS (home subscriber server) whether the corresponding terminal (UE#1) or the caller can use the caller-related indication information through a third-party service. Alternatively, when the terminal requests a service, the caller-related indication information provided by the third-party service is included or the caller-related indication information-related information (3) rd An IMS AS (IMS AS-O) that receives a SIP INVITE message including a caller ID can receive server information of a third-party service provider that provides caller-related indication information from the HSS.

[0094] In one embodiment of the present disclosure, an IMS AS (IMS AS-O) that receives a SIP INVITE message including request information for provision of caller-related indication information using a caller authentication system from an S-CSCF (S-CSCF#1) may request an HSS (home subscriber server) to confirm whether the terminal (UE#1) or the caller can use caller-related indication information through a third-party service.

[0095] In one embodiment of the present disclosure, the HSS includes caller-related indication information provided by a third service when a terminal requests a service in response to the request, or caller-related indication information related information (3 rd The IMS AS (IMS AS-O) that received the SIP INVITE message including the party ID can respond with the server information of a third-party service provider that provides caller-related display information.

[0096] In steps 406 and 407, the IMS AS (IMS AS-O) that has received the server information of the third-party service provider that provides caller-related indication information from the HSS sends the 3rd party service provider's server the 3rd party service provider's server that has received the caller-related indication information from the terminal. rd By transmitting the party ID, the call data of the corresponding caller provided by the third-party service provider can be requested. In addition, the IMS AS (IMS AS-O) receives the 3rd party ID from the terminal. rd A request may be made to a third-party service provider server to verify whether the party ID can actually be used by the user. If the caller's call data provided by the third-party service provider, such as caller ID, is updated or changed, rd If the party ID is updated, the updated 3 rdYou can request that the party ID be transmitted to IMS AS (IMS AS-O) so that it can be transmitted together with the SIP INVITE response message transmitted to the terminal (UE #1).

[0097] In steps 408 and 409, a sender authentication system using sender-related indication information provided by a third-party service provider may authenticate or sign the corresponding sender information and encrypt the sender-related indication information in a Signing AS. In the case of sender-related indication information provided by a third-party service provider, authentication of the sender information and encryption of the sender-related indication information may be performed through a separate Signing AS. If authentication of the sender information and encryption of the sender-related indication information through a separate Signing AS are required, the third-party service provider may store the third-party service provider server address and the Signing AS address together in the HSS. In this case, the IMS AS (IMS AS-O) may receive the third-party service provider server address and the Signing AS address together from the HSS in step 405. The Signing AS may be referred to as having the same meaning as an AS for signing.

[0098] In one embodiment of the present disclosure, in a sender authentication system using sender-related indication information provided by a third-party service provider, an operation of authenticating or signing the sender information may be an operation in which a first IMS AS transmits a signing request message for the sender-related indication information to a Signing AS.

[0099] In one embodiment of the present disclosure, in the case of sender-related indication information provided by a third-party service provider, the operation of performing the authentication of sender information and the encryption of sender-related indication information through a separate Signing AS may be an operation of the Signing AS transmitting an encrypted message corresponding to a signing request message to the first IMS AS.

[0100] In steps 410 to 412, the IMS AS (IMS AS-O) may forward the SIP INVITE message including the encrypted caller-related indication information, which has undergone the authentication and encryption process of the caller information from the caller system, to the S-CSCF (S-CSCF#2) of the counterpart network through the Egress IBCF and the Ingress IBCF of the counterpart network. The S-CSCF (S-CSCF#2) of the counterpart network (Terminating) may forward the SIP INVITE message including the encrypted caller-related indication information to the Terminating IMS AS (IMS AS-T) to request a verification and decryption process of the encrypted caller-related indication information.

[0101] In steps 413 and 414, the terminating IMS AS (IMS AS-T) transmits the encrypted sender-related indication information to the verification AS (AS for Verification) to request a verification and decryption process of the encrypted sender-related indication information, and then receives the decrypted sender-related indication information from the verification AS (AS for Verification). The verification AS may be referred to as the same meaning as the AS for verification.

[0102] In one embodiment of the present disclosure, a terminating IMS AS (IMS AS-T) may transmit encrypted sender-related indication information to a verification AS (AS for Verification), transmit a request for a verification and decryption process of the encrypted sender-related indication information, and then receive the verified sender-related indication information from the verification AS (AS for Verification).

[0103] In step 415, the terminating IMS AS (IMS AS-T) can update the SIP INVITE message based on the decrypted caller information received from the verification AS (AS for Verification). The terminating IMS AS (IMS AS-T) can forward the SIP INVITE message including the caller identification information to the service counterpart terminal (UE #2) via the terminating-side S-CSCF (S-CSCF#2).

[0104] In step 416, the service counterpart terminal (UE#2) can display the caller ID information received from the terminal (UE#1) on the display.

[0105] FIG. 5 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0106] Referring to FIG. 5, in step 501, the terminal (UE#1) may transmit a SIP INVITE message to an existing CSCF, such as a P-CSCF and an S-CSCF, to request a call session connection. The SIP INVITE message includes IMPU, IMPI, Calling ID, Caller ID, IMSI, and 3 rdAt least one terminal (UE #1)-related information among the party service IDs and at least one service counterpart terminal (UE #2)-related information among IMPU, IMPI, Called ID, Callee ID, and IMSI may be included. Additionally, if caller-related indication information is provided through multiple third-party services, the terminal (UE #1) may include a preferred group ID or group category information in the SIP INVITE message to distinguish the caller-related indication information.

[0107] In steps 502 and 503, the S-CSCF (S-CSCF#1) that receives the SIP INVITE including the above SDP information checks whether the SIP INVITE includes a call service related SDP offer, and if so, can forward the content of the SDP offer to the IMS AS (Telephony AS). At this time, the S-CSCF (S-CSCF#1) can forward the SDP offer to the IMS AS (IMS AS-O) that supports the caller ID information authentication function if the IMS call service requires the caller information authentication function according to the policies of the network operator and service provider. If there is no separate policy or setting, the S-CSCF (S-CSCF#1) can determine whether or not to support the caller ID information authentication function if the SIP INVITE message transmitted from the terminal includes caller-related indication information (e.g., RCD) or the terminal determines the need for supporting the caller information authentication function through a separate service indicator, etc.

[0108] In steps 504 to 506, the IMS AS (IMS AS-O) that receives a SIP INVITE message including request information for providing caller-related indication information using a caller authentication system from the S-CSCF (S-CSCF#1) can first confirm from the HSS whether the corresponding terminal (UE#1) or the caller can use caller-related indication information through a third-party service. In step 504, if the IMS AS (IMS AS-O) additionally transmits the preferred group ID or group category information transmitted from the terminal (UE#1) to the HSS and the HSS finds caller-related indication information provided by multiple third-party services based on the terminal information (Caller ID), the HSS selects one third-party service that provides caller-related indication information based on the preferred group ID or group category information in step 505, and the IMS AS (IMS AS-O) can receive this from the HSS in step 506. In one embodiment, the IMS AS (IMS AS-O) may perform an operation of selecting one of a plurality of third-party services that provide caller-related indication information transmitted in step 506 using the preferred group ID or group category information without transmitting the preferred group ID or group category information to the HSS. In this case, step 505 may be omitted. The IMS AS (IMS AS-O) may receive third-party operator service server information that provides caller-related indication information from the HSS through steps 504 to 506.

[0109] In steps 507 and 508, the IMS AS (IMS AS-O) that has received server information of a third-party service provider that provides caller-related display information from the HSS can request and receive call data of the corresponding caller provided by the third-party service provider by transmitting the Caller ID received from the terminal to the server of the third-party service provider.

[0110] In steps 509 and 510, a sender authentication system using sender-related indication information provided by a third-party service provider may authenticate the corresponding sender information and encrypt the sender-related indication information in a Signing AS. In the case of sender-related indication information provided by a third-party service provider, the authentication of the sender information and the encryption of the sender-related indication information may be performed through a separate Signing AS. If it is necessary to perform the authentication of the sender information and the encryption of the sender-related indication information through a separate Signing AS, the third-party service provider may store the third-party service provider server address and the Signing AS address together in the HSS. In this case, the IMS AS (IMS AS-O) may receive the third-party service provider server address and the Signing AS address together from the HSS in step 506.

[0111] In steps 511 to 513, the IMS AS (IMS AS-O) may forward the SIP INVITE message including the encrypted caller-related indication information, which has undergone the authentication and encryption process of the caller information from the caller system, to the S-CSCF (S-CSCF#2) of the counterpart network through the Egress IBCF and the Ingress IBCF of the counterpart network. The S-CSCF (S-CSCF#2) of the counterpart network (Terminating) may forward the SIP INVITE message including the encrypted caller-related indication information to the Terminating IMS AS (IMS AS-T) to request a verification and decryption process of the encrypted caller-related indication information.

[0112] In steps 514 and 515, the terminating IMS AS (IMS AS-T) transmits the encrypted sender-related indication information to the verification AS (AS for Verification) to request a verification and decryption process of the encrypted sender-related indication information, and then receives the decrypted sender-related indication information from the verification AS (AS for Verification).

[0113] In step 516, the terminating IMS AS (IMS AS-T) can update the SIP INVITE message based on the decrypted caller information received from the verification AS (AS for verification). The terminating IMS AS (IMS AS-T) can forward the SIP INVITE message including the caller identification information to the service counterpart terminal (UE #2) via the terminating-side S-CSCF (S-CSCF#2).

[0114] In step 517, the service counterpart terminal (UE#2) can display the caller ID information received from the terminal (UE#1) on the display.

[0115] FIG. 6 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0116] Referring to FIGS. 6a and 6b, in step 601, the terminal (UE#1) may transmit a SIP INVITE message to an existing CSCF, such as a P-CSCF and an S-CSCF, to request a call session connection. The SIP INVITE message may include IMPU, IMPI, Calling ID, Caller ID, IMSI, and 3 rd At least one terminal (UE #1)-related information among the party service IDs and at least one service counterpart terminal (UE #2)-related information among IMPU, IMPI, Called ID, Callee ID, and IMSI may be included. Additionally, if caller-related indication information is provided through multiple third-party services, the terminal (UE #1) may include a preferred group ID or group category information in the SIP INVITE message to distinguish the caller-related indication information.

[0117] In steps 602 and 603, the S-CSCF (S-CSCF#1) that receives the SIP INVITE including the above SDP information checks whether the SIP INVITE includes a call service related SDP offer, and if so, can forward the content of the SDP offer to the IMS AS (Telephony AS). At this time, the S-CSCF (S-CSCF#1) can forward the SDP offer to the IMS AS (IMS AS-O) that supports the caller ID information authentication function if the IMS call service requires the caller information authentication function according to the policies of the network operator and service provider. If there is no separate policy or setting, the S-CSCF (S-CSCF#1) can determine whether or not to support the caller ID information authentication function if the SIP INVITE message transmitted from the terminal includes caller-related indication information (e.g., RCD) or the terminal determines the need for supporting the caller information authentication function through a separate service indicator, etc.

[0118] In steps 604 and 605, the IMS AS (IMS AS-O) that receives the SIP INVITE message including the request information for providing caller-related indication information using the caller authentication system from the S-CSCF (S-CSCF#1) can first check with the HSS whether the corresponding terminal (UE#1) or the caller can use the caller-related indication information through a third-party service. If the HSS finds multiple third-party services that provide caller-related indication information based on the terminal information (Caller ID), the IMS AS (IMS AS-O) can receive information on each third-party operator service server from the HSS.

[0119] In steps 606a, 607a and 606b, 607b, the IMS AS (IMS AS-O) that has received server information of multiple third-party service providers providing caller-related indication information from the HSS, sends the information to each of the third-party service providers' servers (3 rd Part storage 1,2) can be used to transmit terminal information (Callee ID) received from the terminal to request confirmation of whether a third-party service provider supports the recipient. For example, if the users of two terminals (UE#1, UE#2) use a common third-party service or belong to a common group based on the caller information (Caller ID) and the recipient information (Callee ID), additional caller information can be provided to the recipient. For example, if the users of two terminals (UE#1, UE#2) belong to the same company group, information that does not need to be separately disclosed to the outside, such as the caller's department or job, can be additionally provided.

[0120] In step 608, the IMS AS (IMS AS-O) provides caller-related indication information to the third-party service provider server 1 (3) via steps 606a, 607a and 606b, 607b. rd part storage 1) and third-party service provider server 2(3 rd After transmitting the recipient information (Callee ID) to part storage 2), each third-party business server (3) rd Based on the response message received from part storage 1,2), a third-party service provider that provides sender-related indication information can be selected. Assuming that one of the third-party service providers 1 and 2 (e.g., third-party service provider 1) can provide recipient-related information, a request for sender-related indication information can be determined through third-party service provider 1.

[0121] If both Third Party Service Providers 1 and 2 can provide information related to the recipient (Callee ID), the IMS AS (IMS AS-O) can select one Third Party Service Provider based on the preferred group ID or group category information received from the terminal (UE#1).

[0122] In steps 609 and 610, a sender authentication system using sender-related indication information provided by a third-party service provider may authenticate the corresponding sender information and encrypt the sender-related indication information in a Signing AS. In the case of sender-related indication information provided by a third-party service provider, the authentication of the sender information and the encryption of the sender-related indication information may be performed through a separate Signing AS. If it is necessary to perform the authentication of the sender information and the encryption of the sender-related indication information through a separate Signing AS, the third-party service provider may store the third-party service provider server address and the Signing AS address together in the HSS. In this case, the IMS AS (IMS AS-O) may receive the third-party service provider server address and the Signing AS address together from the HSS in step 605.

[0123] In steps 611 to 613, the IMS AS (IMS AS-O) may forward the SIP INVITE message including the encrypted caller-related indication information, which has undergone the authentication and encryption process of the caller information from the caller system, to the S-CSCF (S-CSCF#2) of the counterpart network through the Egress IBCF and the Ingress IBCF of the counterpart network. The S-CSCF (S-CSCF#2) of the counterpart network (Terminating) may forward the SIP INVITE message including the encrypted caller-related indication information to the Terminating IMS AS (IMS AS-T) to request a verification and decryption process of the encrypted caller-related indication information.

[0124] In steps 614 and 615, the terminating IMS AS (IMS AS-T) transmits the encrypted sender-related indication information to the verification AS (AS for Verification) to request a verification and decryption process of the encrypted sender-related indication information, and then receives the decrypted sender-related indication information from the verification AS (AS for Verification).

[0125] In step 616, the terminating IMS AS (IMS AS-T) can update the SIP INVITE message based on the decrypted caller information received from the verification AS (AS for verification). The terminating IMS AS (IMS AS-T) can forward the SIP INVITE message including the caller identification information to the service counterpart terminal (UE #2) via the terminating-side S-CSCF (S-CSCF#2).

[0126] In step 617, the service counterpart terminal (UE#2) can display the caller ID information received from the terminal (UE#1) on the display.

[0127] FIG. 7 is a flowchart illustrating an operation for generating user (sender) related information of a terminal using a third service based on an IMS service according to one embodiment of the present disclosure and transmitting the user related information of the terminal using a sender authentication system.

[0128] Referring to FIG. 7, in step 701, the terminal (UE#1) may transmit a SIP INVITE message to an existing CSCF, such as a P-CSCF and an S-CSCF, to request a call session connection. The SIP INVITE message includes IMPU, IMPI, Calling ID, Caller ID, IMSI, and 3 rd Among the party service IDs, at least one terminal (UE #1) related information and at least one service counterpart terminal (UE #2) related information among IMPU, IMPI, Called ID, Callee ID, and IMSI may be included.

[0129] In steps 702 and 703, the S-CSCF (S-CSCF#1) that receives the SIP INVITE including the above SDP information checks whether the SIP INVITE includes a call service related SDP offer, and if so, can forward the content of the SDP offer to the IMS AS (Telephony AS). At this time, the S-CSCF (S-CSCF#1) can forward the SDP offer to the IMS AS (IMS AS-O) that supports the caller ID information authentication function if the IMS call service requires the caller information authentication function according to the policies of the network operator and service provider. If there is no separate policy or setting, the S-CSCF (S-CSCF#1) can determine whether or not to support the caller ID information authentication function if the SIP INVITE message transmitted from the terminal includes caller-related indication information (e.g., RCD) or the terminal determines the need for supporting the caller information authentication function through a separate service indicator, etc.

[0130] In steps 704 to 706, the IMS AS (IMS AS-O) that receives a SIP INVITE message including request information for providing caller-related indication information using a caller authentication system from the S-CSCF (S-CSCF#1) can first confirm from the HSS whether the corresponding terminal (UE#1) or the caller can use caller-related indication information through a third-party service. In step 704, the IMS AS (IMS AS-O) additionally transmits to the HSS the time information (time info) or the location information (location info) of the terminal received from the terminal (UE#1), and if the HSS finds caller-related indication information provided by multiple third-party services based on the terminal information (Caller ID) in step 705, the HSS can additionally provide the IMS AS (IMS AS-O) with information for selecting one third-party service. If the HSS selects a third-party service that provides caller ID information in step 705, the IMS AS (IMS AS-O) can receive the third-party service provider server information from the HSS in step 706.

[0131] In steps 707 and 708, the IMS AS (IMS AS-O) that has received server information of a third-party service provider that provides caller-related display information from the HSS can request and receive call data (e.g., RCD) of the corresponding caller provided by the third-party service provider by transmitting the Caller ID received from the terminal to the server of the third-party service provider.

[0132] In steps 709 and 710, a sender authentication system using sender-related indication information provided by a third-party service provider may authenticate the corresponding sender information and encrypt the sender-related indication information in a Signing AS. In the case of sender-related indication information provided by a third-party service provider, the authentication of the sender information and the encryption of the sender-related indication information may be performed through a separate Signing AS. If it is necessary to perform the authentication of the sender information and the encryption of the sender-related indication information through a separate Signing AS, the third-party service provider may store the third-party service provider server address and the Signing AS address together in the HSS. In this case, the IMS AS (IMS AS-O) may receive the third-party service provider server address and the Signing AS address together from the HSS in step 706.

[0133] In steps 711 to 713, the IMS AS (IMS AS-O) may forward the SIP INVITE message including the encrypted caller-related indication information, which has undergone the authentication and encryption process of the caller information from the caller system, to the S-CSCF (S-CSCF#2) of the counterpart network through the Egress IBCF and the Ingress IBCF of the counterpart network. The S-CSCF (S-CSCF#2) of the counterpart network (Terminating) may forward the SIP INVITE message including the encrypted caller-related indication information to the Terminating IMS AS (IMS AS-T) to request a verification and decryption process of the encrypted caller-related indication information.

[0134] In steps 714 and 715, the terminating IMS AS (IMS AS-T) transmits the encrypted sender-related indication information to the verification AS (AS for Verification) to request a verification and decryption process of the encrypted sender-related indication information, and then receives the decrypted sender-related indication information from the verification AS (AS for Verification).

[0135] In step 716, the terminating IMS AS (IMS AS-T) can update the SIP INVITE message based on the decrypted caller information received from the verification AS (AS for verification). The terminating IMS AS (IMS AS-T) can forward the SIP INVITE message including the caller identification information to the service counterpart terminal (UE #2) via the terminating-side S-CSCF (S-CSCF#2).

[0136] In step 717, the service counterpart terminal (UE#2) can display the caller ID information received from the terminal (UE#1) on the display.

[0137] In one embodiment of the present disclosure, a method of a first IMS (internet protocol multimedia core network subsystem) AS (application server) in a wireless communication system may receive a first SIP (session initiation protocol) invite message including third party identification information from a first UE (user equipment).

[0138] In one embodiment of the present disclosure, the first IMS AS can confirm RCD (rich call data) related information from an HSS (home subscriber server) in response to the first SIP invitation message.

[0139] In one embodiment of the present disclosure, the first IMS AS can receive, from the HSS, address information of an RCD server included in the RCD-related information.

[0140] In one embodiment of the present disclosure, the first IMS AS can check RCD information with the RCD server.

[0141] In one embodiment of the present disclosure, the first IMS AS may be an application server for signing (AS) and may transmit a signing request message for the RCD information.

[0142] In one embodiment of the present disclosure, the first IMS AS may receive an encrypted message corresponding to the signature request message from the AS for signing.

[0143] In one embodiment of the present disclosure, the first IMS AS may transmit a second SIP invitation message including the encrypted message to the second IMS AS.

[0144] In one embodiment of the present disclosure, the second SIP invitation message may be verified in an application server for verification (AS).

[0145] In one embodiment of the present disclosure, the verified second SIP invitation message may be transmitted to a second terminal.

[0146] In one embodiment of the present disclosure, the RCD related information can be received from an application function (AF).

[0147] In one embodiment of the present disclosure, user information related to the RCD-related information can be transmitted from AF to NEF (network exposure function).

[0148] Figure 8 is a device diagram of a terminal according to one embodiment of the present disclosure.

[0149] In the embodiment of FIG. 8, the terminal may be a UE or terminal illustrated in each of FIGS. 1 to 7. Referring to FIG. 8, the terminal may include a transceiver unit (810), a control unit (820), and a storage unit (830).

[0150] The transceiver (810) can transmit and receive signals with a base station or network entity. The transceiver (810) can transmit and receive data with the base station or network entity, for example, using wireless communication. In the present disclosure, the transceiver (810) may also be referred to as a transceiver or transceiver.

[0151] The control unit (820) can control the overall operation of the terminal according to the embodiment proposed in this disclosure. For example, the control unit (820) can control the signal flow between each block to perform the operations described with reference to FIGS. 1 to 7. In this disclosure, the control unit (820) can be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0152] The storage unit (830) can store at least one of information transmitted and received via the transceiver unit (810) and information generated via the control unit (820). In the present disclosure, the storage unit (830) may also be referred to as a memory. For example, the storage unit (830) can store information and data required for the method described with reference to FIGS. 1 to 7 .

[0153] FIG. 9 is a device diagram of a network entity according to one embodiment of the present disclosure.

[0154] In the embodiment of FIG. 9, the network entities are the base station (RAN), P-CSCF, S-CSCF, IMS AS, HSS, 3 shown in FIGS. 1 to 7, respectively. rd It can be implemented as one of party storage, AS. Referring to FIG. 9, the network entity can include a transceiver unit (910), a control unit (920), and a storage unit (930).

[0155] The transceiver (910) can transmit and receive signals with a terminal, base station, or other network entity. The transceiver (910) can transmit and receive data with the terminal, base station, or other network entity, for example, using wireless communication. In the present disclosure, the transceiver (910) may also be referred to as a transceiver.

[0156] The control unit (920) can control the overall operation of a network entity according to an embodiment proposed in this disclosure. For example, the control unit (920) can control the signal flow between each block to perform the operations described with reference to FIGS. 1 to 7. In this disclosure, the control unit (920) can be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0157] The storage unit (930) can store at least one of the information transmitted and received via the transceiver unit (910) and the information generated via the control unit (920). In the present disclosure, the storage unit (930) may also be referred to as a memory. For example, the storage unit (930) can store information and data required for the method described with reference to FIGS. 1 to 7 .

[0158] 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.

[0159] 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.

[0160] These programs (software modules, software) may be stored in a non-volatile memory including random access memory, flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc ROMs (CD-ROMs), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or 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.

[0161] 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.

[0162] In the specific embodiments of the present disclosure described above, components included in the present 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.

[0163] 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.

Claims

1. In a method of a first IMS (internet protocol multimedia core network subsystem) AS (application server) in a wireless communication system, A process of receiving a first SIP (session initiation protocol) invite message including third party identification information from a first UE (user equipment); In response to the first SIP invitation message, a process of checking RCD (rich call data) related information from an HSS (home subscriber server); and A method comprising: a process of receiving address information of an RCD server included in the RCD-related information from the HSS; 2. In paragraph 1, A method further comprising: a process of checking RCD information with the RCD server; 3. In paragraph 2, A process of sending a signing request message for the RCD information to an AS (application server for signing) for signing; and A method further comprising: a process of receiving an encrypted message corresponding to the signature request message from the AS for the signature; 4. In paragraph 3, A method further comprising: a process of transmitting a second SIP invitation message including the above-described encrypted message to a second IMS AS; 5. A method according to claim 4, wherein the second SIP invitation message is verified in an application server for verification (AS).

6. In the fifth paragraph, the verified second SIP invitation message is transmitted to the second terminal.

7. In the first paragraph, the RCD-related information is received from an application function (AF).

8. A method according to claim 7, wherein user information related to the RCD-related information is transmitted from AF to NEF (network exposure function).

9. In the first IMS (internet protocol multimedia core network subsystem) AS (application server) in a wireless communication system, Transmitter and receiver; memory; and comprising at least one processor, said at least one processor comprising: Receive a first SIP (session initiation protocol) invite message containing third party identification information from a first UE (user equipment), In response to the above first SIP invitation message, check the RCD (rich call data) related information from the HSS (home subscriber server), and A first IMS AS configured to receive, from the HSS, address information of an RCD server included in the RCD-related information.

10. In the 9th paragraph, the at least one processor, A first IMS AS further configured to check RCD information with the above RCD server.

11. In the 10th paragraph, the at least one processor, As an AS (application server for signing), it sends a signing request message for the above RCD information, and A first IMS AS further configured to receive an encrypted message corresponding to the signature request message from the AS for the signature.

12. In the 11th paragraph, the at least one processor, A first IMS AS further configured to transmit a second SIP invitation message including the above-described encrypted message to a second IMS AS.

13. In the 12th paragraph, the second SIP invitation message is verified in an application server for verification (AS).

14. In the 13th paragraph, the verified second SIP invitation message is transmitted to the second terminal, the first IMS AS.

15. In paragraph 9, the RCD related information is received from an AF (application function) entity, the first IMS AS.

Images