Procedures for the IMS framework to support the authorization and authentication of third-party user identities in IMS sessions

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transfer rates. The present disclosure relates to the authorization and authentication of third-party user identities in IMS sessions. The method comprises the step of receiving a call setup message from a UE during an IMS session by an IMS sending network device. Additionally, the method comprises the step of retrieving the UE's subscription information from an HSS to determine whether the UE is authorized to use third-party user identity information. Additionally, the method comprises the step of retrieving the third-party user identity information from an HSS if the UE is successfully authorized. Additionally, the method comprises the step of transmitting an INVITE message containing the signed third-party information to an IMS receiving network device to verify the signed third-party information and establish a call with the receiving UE when the verification is successful.

Description

Technology Field

[0001] The proposed embodiments relate to an IP Multimedia Subsystem (IMS) framework. More specifically, the present disclosure relates to a procedure for the IMS framework to support the authorization and authentication of third-party user identities in IMS sessions. Background Technology

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

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

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

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

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

[0007] Furthermore, the advancement of these 5G mobile communication systems serves as a foundation for developing new waveforms to provide coverage in the terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas, and massive antennas, metamaterial-based lenses and antennas to improve coverage of terahertz band signals, high-dimensional spatial multiplexing technologies using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surfaces (RIS); as well as full-duplex technologies to increase frequency efficiency and improve system networks of 6G mobile communication technologies, AI-based communication technologies that achieve system optimization by utilizing satellites and Artificial Intelligence (AI) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technologies that implement services at complexity levels exceeding the limits of UE operational capability using ultra-high-performance communication and computing resources. will do. means of solving the problem

[0008] In one embodiment, a method is provided for authorization and authentication of a third-party user identity in an IP multimedia subsystem (IMS) to be performed by a sending IMS network. The method may include the step of receiving an invitite from a user equipment (UE). The method may include the step of obtaining subscription information of the UE from a home subscriber server (HSS). The method may include the step of identifying whether the UE is authorized to use the third-party user identity based on the subscription information. The method may include the step of obtaining the third-party user identity from the HSS based on identifying that the UE is authorized to use the third-party user identity. The method may include the step of transmitting the invitite containing the signed third-party user identity to a receiving IMS network.

[0009] In one embodiment, a method is provided for authorization and authentication of a third-party user identity in an IP multimedia subsystem (IMS) by a receiving IMS network. The method may include the step of receiving an INVITE containing a signed third-party user identity from a sending IMS network. The method may include the step of transmitting the INVITE containing the signed third-party user identity to a verification server. The method may include the step of receiving a verification result of the signed third-party user identity from the verification server, wherein the result may be success or failure. Based on a successful verification of the signed third-party user identity, the method may include the step of transmitting an INVITE containing the verified third-party user identity to a receiving UE.

[0010] In one embodiment, a method is provided for authorization and authentication of a third-party user identity in an IP multimedia subsystem (IMS) by a home subscriber server (HSS). The method may include the step of receiving the third-party user identity and third-party user identity usage parameters from a third-party device, wherein the third-party is at least one of a trusted application function or an untrusted application function. The method may include the step of storing the third-party user identity and third-party user identity usage parameters received from the third-party device.

[0011] In one embodiment, a sending IMS network device for authorizing and authenticating a third-party user identity in an IP multimedia subsystem (IMS) is provided. The sending IMS network device may include a processor and an IMS session control unit connected to communicate with the processor. The IMS session control unit may receive an INVITE from a user terminal (UE). The IMS session control unit may obtain subscription information of the UE from a home subscriber server (HSS). Based on the subscription information, the IMS session control unit may identify whether the UE is authorized to use the third-party user identity. Based on identifying that the UE is authorized to use the third-party user identity, the IMS session control unit may obtain the third-party user identity from the HSS. The IMS session control unit may transmit the INVITE containing the signed third-party user identity to a receiving IMS network device.

[0012] In one embodiment, a receiving IMS network device is provided for authorizing and authenticating a third-party user identity in an IP multimedia subsystem (IMS). The receiving IMS network device may include a processor and an IMS session control unit connected to communicate with the processor. The IMS session control unit may receive an INVITE containing a signed third-party user identity from a sending IMS network device. The IMS session control unit may transmit the INVITE containing the signed third-party user identity to a verification server. The IMS session control unit may receive a verification result of the signed third-party user identity from the verification server, and the result may be success or failure. Based on the successful verification of the signed third-party user identity information, the IMS session control unit may transmit an INVITE containing the verified third-party user identity to a receiving UE.

[0013] In one embodiment, a home subscriber server (HSS) is provided for authorizing and authenticating a third-party user identity in an IP multimedia subsystem (IMS). The HSS may include a processor and an IMS session control unit connected to communicate with the processor. The IMS session control unit may receive the third-party user identity and third-party user identity usage parameters from a third-party device, wherein the third-party is at least one of a trusted application function or an untrusted application function. The IMS session control unit may store the third-party user identity and third-party user identity usage parameters received from the third-party device.

[0014] These and other aspects of the embodiments of the present disclosure will be better recognized and understood when considered in conjunction with the following description and the accompanying drawings. However, it should be understood that the following description is given by way of example and is not limiting, while illustrating preferred embodiments and numerous specific details thereof. Many changes and modifications may be made within the scope of the embodiments of the present disclosure. Brief explanation of the drawing

[0015] These and other features, aspects, and advantages of the embodiments are illustrated in the accompanying drawings, and throughout the drawings, similar reference numerals indicate corresponding parts in various drawings. Embodiments of the present disclosure will be better understood from the following description with reference to the drawings, among which: FIG. 1 is a block diagram of an IMS originating network device for authorizing and authenticating a third-party user identity in an IMS session according to one embodiment of the present disclosure. FIG. 2 is a block diagram of an IMS terminating network device for authorizing and authenticating a third-party user identity in an IMS session according to one embodiment of the present disclosure. FIG. 3 is a flowchart illustrating a method for authorizing and authenticating a third-party user identity in an IMS session by an IMS sending network device according to one embodiment of the present disclosure. FIG. 4 is a flowchart illustrating a method for authorizing and authenticating a third-party user identity in an IMS session by an IMS receiving network device according to one embodiment of the present disclosure. FIG. 5a is a block diagram of an HSS for authorizing and authenticating a third-party user identity within an IMS session by the HSS according to one embodiment of the present disclosure. FIG. 5b is a flowchart illustrating a method for performing authorization and authentication of a third-party user identity within an IMS session by an HSS according to one embodiment of the present disclosure. FIG. 6 is a sequence diagram illustrating the authorization and authentication process of a third-party user identity within an IMS session according to one embodiment of the present disclosure. FIG. 7 is a sequence diagram illustrating the signing and verification process of third-party user identity information in an IMS according to one embodiment of the present disclosure. FIG. 8 is a sequence diagram illustrating a process for provisioning IMS user-specific attributes according to one embodiment of the present disclosure. Specific details for implementing the invention

[0016] It may be noted that, to the extent possible, similar reference numbers have been used to denote similar elements in the drawings. Furthermore, those skilled in the art will acknowledge that elements in the drawings are drawn for simplification and may not necessarily be drawn to scale. For example, the dimensions of some elements in the drawings may be exaggerated relative to others to improve understanding of the embodiments of the present disclosure. Moreover, elements may be represented in the drawings by conventional symbols, and the drawings may show only specific details relevant to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that would be readily apparent to those skilled in the art who have the advantage of the description of the present disclosure.

[0017] As is traditional in the art, embodiments are described and illustrated in terms of the described functions or blocks performing the functions. These blocks, referred herein to as managers, units, modules, hardware components, etc., are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may be optionally driven by firmware and software. The circuits may be implemented, for example, within one or more semiconductor chips or on substrate supports such as printed circuit boards. The circuits constituting the blocks may be implemented by dedicated hardware, by a processor (e.g., one or more programmed microprocessors and associated circuits), or by a combination of dedicated hardware performing some functions of the block and a processor performing other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and individual blocks without departing from the scope of the proposed method. Similarly, the blocks of the embodiments can be physically combined into more complex blocks without going beyond the scope of the proposed method.

[0018] It is understood that the accompanying drawings are intended to facilitate understanding of various technical features and that the embodiments presented in this disclosure are not limited by the accompanying drawings. As such, the proposed method is to be interpreted as extending to any modifications, equivalents, and substitutions in addition to those presented particularly in the accompanying drawings. Although terms such as "first," "second," etc., are used in this disclosure to describe various elements, these elements are not limited by these terms. These terms are generally used to distinguish one element from another.

[0019] Advancements in telecommunications technology have significantly transformed how businesses operate, and Multimedia Telephony (MMTEL) services have played a pivotal role in this transformation. MMTEL services extend beyond traditional voice calls to include a wide range of capabilities, such as online meetings, messaging, and advanced applications like Augmented Reality (AR) and Virtual Reality (VR) calls. These services have become an essential part of various business functions, including internal communications, sales interactions, customer support, and contact center operations. Despite these clear advantages, companies face several challenges when utilizing MMTEL services.

[0020] One of the major challenges involves managing internal communications. Organizations utilize MMTELs for voice calls, online meetings, and collaboration features such as screen sharing and messaging. However, managing individual employee subscriptions can be cumbersome, particularly in dynamic business environments where employees frequently join, leave, or move internationally. This complexity can lead to inefficiencies and increased operating costs, especially in large organizations with a global presence.

[0021] Another significant issue arises in communication with current and potential customers. While MMTEL services provide features before, during, and after calls, companies often face issues related to call authenticity. A concern is rejecting legitimate business calls as fraudulent or robocalls. This does not disrupt communication but impacts customer relationships and business reputation.

[0022] Addressing these challenges involves strengthening authentication and authorization processes within the IP Multimedia Subsystem (IMS) architecture. The 3rd Generation Partnership Project (3GPP) is investigating the authentication and authorization of third-party user identities in IMS sessions in Release 19. This includes developing mechanisms for serving IMS networks to authorize third-party user identities and enabling receiving IMS networks to verify these identities. Strengthening IMS procedures related to the authentication, authorization, signing, and verification of third-party user identities is also being studied, including potential impacts on existing standards such as STIR / SHAKEN.

[0023] Furthermore, there is a need to enhance IMS subscriber data to support third-party user identities across various use cases, such as verifying identities in Originating Identification Presentation (OIP) services and using identities in IMS avatar communications. These enhancements are used to ensure secure and reliable communications and require coordination with security working groups to comprehensively address relevant security aspects. Until then, while MMTEL services offer significant benefits for business communications, they also present several challenges that need to be addressed to ensure the efficient, secure, and reliable use of these services.

[0024] In this way, it is desirable to resolve the disadvantages, problems, or other shortcomings mentioned above, or at least provide a useful alternative.

[0025] The primary purpose of the embodiments of the present disclosure is to relate to an IMS framework for supporting the authorization and authentication of third-party user identities in IMS sessions.

[0026] The purpose of the present disclosure may be for an IMS network to authorize and authenticate a calling party when using third-party specific identities.

[0027] The purpose of the present disclosure may be to ensure that the called party receives a call from the intended user.

[0028] The purpose of the present disclosure may be to provision third-party information to the HSS by means of AF.

[0029] The purpose of the present disclosure may be to sign third-party user identities by a signature server of the sending party and verify them by a verification server of the receiving party.

[0030] The present disclosure proposes a solution for an IMS network to authorize a user when the user uses a third-party identity in an IMS session. The following are the key principles of this solution.

[0031] Authentication and authorization of a third-party identity in each session will add a delay to the call setup time, regardless of whether it is required. Therefore, the IMS network must selectively identify sessions that require this third-party identity authentication and authorization.

[0032] It is proposed that a third party providing third-party identities to its users for use during an IMS session provides this information to the operator, and that the operator retains this information in the subscriber profile.

[0033] A subscriber profile within a Home Subscriber Server (HSS) for a subscriber / user (e.g., IP Multimedia Public Identity (IMPU)) will have a parameter indicating whether authentication and authorization of a third-party identity are required. Additionally, the subscriber profile includes third-party identities to be used by the user (IMPU). If the third-party identity is common / identical for all users, the third party may create a group containing a list of third-party users / IMPUs along with the third-party identity and provide this to the HSS via a Network Exposure Function (NEF).

[0034] During an IMS session, the outgoing serving call session control function (S-CSCF) must check subscription information when it receives an INVITE from a user terminal (User Equipment, UE). When parameters indicate that third-party identity authentication and authorization are required, the S-CSCF proceeds.

[0035] Third-party identity information can be retrieved by the S-CSCF from the PAI / header or some Call-Info header (some other SIP headers used by the UE to transmit third-party identity) and then compared with the stored third-party identities from the subscriber profile.

[0036] Upon a successful match, the S-CSCF calls the signature server (STI-AS). The network obtains this signature server address from the subscription information.

[0037] Then, the signing server will receive the INVITE from the IMS sending network / S-CSCF, add an identity header in accordance with TS 24.229, and sign it.

[0038] Next, the IMS receiving network / S-CSCF calls the verification server based on the presence of the identity header. The verification server address is set in the S-CSCFs / IBCFs.

[0039] Then, the validation server provides a validation status in accordance with TS 24.229.

[0040] Now, with reference to the drawings, particularly FIGS. 1 through 8, in which similar reference numerals consistently indicate corresponding features throughout the drawings, preferred embodiments are illustrated.

[0041] FIG. 1 is a block diagram of an IMS originating network device for authorizing and authenticating a third-party user identity in an IMS session according to one embodiment of the present disclosure. The IMS originating network device (101) may include a processor (103), memory (105), an I / O interface (107), and an IMS session control unit (109). The IMS originating network device (101) may include network entities such as an Originating Serving-Call Session Control Function (OS-CSCF) and a Secure Telephone Identity-Authentication Server (STI-AS). Furthermore, the processor (103) of the IMS originating network device (101) may communicate with the memory (105), the I / O interface (107), and the IMS session control unit (109). The processor (103) may be configured to execute instructions stored in memory (105) and perform various processes. The processor (103) may include one or more processors, such as a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), a graphics processing unit, such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an artificial intelligence (AI) processor, such as a neural processing unit (NPU).

[0042] Additionally, the memory (105) of the IMS sending network device (101) may include storage locations that can be addressed via the processor (103). The memory (105) is not limited to volatile or non-volatile memory and may include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical disks, floppy disks, flash memory, EPROM, or EEPROM memory may also be included in the memory (105). Additionally, the memory (105) of the IMS sending network device (101) may store various information received from the UE and the IMS receiving network device (201). The IMS sending network device (101) may store some information, such as subscriber information and Rich Call Data (RCD) information received from the HSS.

[0043] The I / O interface (107) can transmit information between the memory (105) and external peripheral devices, which are input / output devices associated with the IMS sending network device (101). The I / O interface (107) can receive various information from the UE, HSS, and IMS receiving network device (201). This interface can be used to maintain seamless communication between the IMS sending network device (101) and external devices, ensuring that data is transmitted and received. Additionally, the I / O interface (107) can facilitate integration between the IMS sending network device (101) and other network components, thereby enhancing the ability to authorize and authenticate third-party user identities in an IMS session.

[0044] The IMS session control unit (109) can communicate with the I / O interface (107) and memory (105) for authorization and authentication of a third-party user identity in an IMS session. The IMS session control unit (109) may be innovative hardware realized through physical implementations of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0045] When a call setup message is received from a user device (UE), the IMS session control unit (109) may initiate a series of authentication and authorization procedures to ensure the safe and legitimate use of network resources. Additionally, the IMS session control unit (109) may retrieve the UE's subscription information from the HSS. The HSS may serve as a central database storing user profiles, subscription details, and authentication credentials, thereby enabling the IMS session control unit (109) to verify the UE's identity and service entitlements.

[0046] Once the subscription information is obtained, the IMS session control unit (109) may determine whether the UE is authorized to use third-party user identity information based on the subscription information. This determination may be made to maintain the integrity and security of the network, as unauthorized use of third-party user identity can lead to fraudulent activities or privacy breaches. The authorization decision may be based on the subscription information retrieved from the HSS, which outlines specific permissions and restrictions associated with the UE's account. Additionally, the IMS session control unit (109) may retrieve the third-party user identity information from the HSS when the UE is successfully authorized to use third-party user identity information, thereby ensuring that the UE can lawfully represent or interact with the third party during the session.

[0047] If the UE is not successfully authorized to use third-party user identity information, the IMS session control unit (109) may reject the call setup message received from the UE. This rejection serves as a protective measure to prevent unauthorized access and potential misuse of network resources. Additionally, if authorization is granted, the IMS session control unit (109) may generate and transmit an INVITE message to the IMS receiving network device (201). This INVITE message includes signed third-party information to verify the UE's authorization to participate in the session using the specified identity. By incorporating the signed third-party information, the IMS session control unit (109) can ensure that the communication session complies with security protocols and maintains the reliability of the IMS environment.

[0048] In one embodiment, the IMS sending network device (101) may be an S-CSCF or an IMS application server (AS), but is not limited thereto. The S-CSCF may act as a central node in the signaling plane. It may be responsible for session control and management, ensuring that multimedia sessions are efficiently established, maintained, and terminated. The S-CSCF may interact with various other components within the IMS, such as a Home Subscriber Server (HSS) for retrieving user profiles and a Media Resource Function (MRF) for managing media-related tasks. By acting as a sending network device, the S-CSCF can ensure the seamless initiation and control of multimedia sessions, thereby providing reliable and high-quality communication services to users.

[0049] Furthermore, IMS AS can extend the capabilities of IMS by hosting and running value-added services and applications. It can be a versatile component capable of supporting a wide range of services, from basic call processing to complex multimedia applications. IMS AS can be customized to meet specific service requirements, enabling service providers to offer innovative and differentiated services to their customers. By acting as an originating network device, IMS AS can initiate service-specific logic and processes, ensuring that users receive personalized and context-aware communication experiences. This flexibility allows service providers to rapidly adapt to changing market demands and introduce new services without significant infrastructure changes.

[0050] In addition to the S-CSCF and IMS AS, the IMS originating network device (101) may also include other components or configurations depending on the specific requirements of the provided networks and services. For example, it may include elements such as a Proxy Call Session Control Function (P-CSCF) or an Interrogating Call Session Control Function (I-CSCF) that perform auxiliary roles in the IMS architecture. While the P-CSCF can serve as the first point of contact for users within the IMS while handling initial signaling and security functions, the I-CSCF can assist with routing and session initiation processes. By integrating these components, the IMS originating network device can provide a comprehensive and robust framework for managing multimedia communications, ensuring that users experience seamless connectivity and access to a wide range of services.

[0051] In one embodiment, the IMS session control unit (109) can determine whether the UE is authorized to use third-party user identity information by checking the third-party user identity information usage parameter in the subscription information for the UE. If the third-party user identity information usage parameter is enabled, the IMS session control unit (109) can conclude that the UE is authorized to use third-party user identity information. Additionally, if the third-party user identity information usage parameter is disabled, the IMS session control unit (109) can determine that the UE is not authorized to use third-party user identity information.

[0052] Third-party user identity information can ensure the integrity and authenticity of communication within the IMS framework. By verifying the authorization status of the UE, the IMS session control unit (109) can maintain a security protocol that protects sensitive identity information from unauthorized access or misuse. This verification process can protect the identity of third parties and improve the reliability of the communication network by ensuring that authorized entities can represent the third-party user identity. The IMS session control unit (109) can act as a gatekeeper and check subscription information to ensure compliance with established security standards.

[0053] In one embodiment, third-party information may include, but is not limited to, sender name, organization information, job title information, and email information per IMPU or per group of IMPUs. This information may provide a comprehensive profile that can be used to authenticate a UE's claim regarding a third-party user identity. By integrating a wide range of identity attributes, the IMS session control unit (109) can perform more thorough verification, thereby reducing the risk of identity spoofing or other fraudulent activities. This multifaceted approach to identity verification can ensure that the communication network remains robust and secure even when accommodating various identity information.

[0054] In one embodiment, to transmit an INVITE message containing signed third-party information to an IMS receiving network device (201), the IMS session control unit (109) may transmit the INVITE message to a signing server to sign the third-party user identity information. Additionally, the IMS session control unit (109) may receive the signed third-party information from the signing server. Once the third-party user identity information is signed, it may provide an cryptographic guarantee of its authenticity, thereby enabling the IMS session control unit (109) to forward the INVITE message to the IMS receiving network device (201) with confidence. By utilizing encryption technology, the IMS session control unit (109) can maintain the overall security and reliability of the IMS communication system by ensuring that the third-party user identity information remains tamper-proof and verifiable.

[0055] FIG. 2 is a block diagram of an IMS receiving network device for authorizing and authenticating a third-party user identity in an IMS session according to one embodiment of the present disclosure.

[0056] The IMS receiving network device (201) may include a processor (203), memory (205), an I / O interface (207), and an IMS session control unit (209). The IMS receiving network device (201) may be an S-CSCF and an IMS AS, but is not limited thereto. Additionally, the processor (203) of the IMS receiving network device (201) may communicate with the memory (205), the I / O interface (207), and the IMS session control unit (209). The processor (203) may be configured to execute instructions stored in the memory (205) and perform various processes. The processor (203) may include one or more processors, such as a general-purpose processor, e.g., a central processing unit (CPU), an application processor (AP), a graphics-dedicated processing unit, e.g., a graphics processing unit (GPU), a visual processing unit (VPU), and / or an artificial intelligence (AI)-dedicated processor, e.g., a neural processing unit (NPU).

[0057] Additionally, the memory (205) of the IMS receiving network device (201) may include storage locations that can be addressed via the processor (203). The memory (205) is not limited to volatile or non-volatile memory and may include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical disks, floppy disks, flash memory, EPROM, or EEPROM memory may also be included in the memory (205). Additionally, the memory (205) of the IMS receiving network device (201) may store various information received from the IMS sending network device (101). The IMS receiving network device (201) may store some information, such as signed RCD information within an INVITE message, an RCD URL (Universal Resource Locator), etc.

[0058] The I / O interface (207) can transmit information between the memory (205) and external peripheral devices, which are input / output devices associated with the IMS receiving network device (201). The I / O interface (207) can receive various information from the UE. This interface can be used to maintain uninterrupted communication between the IMS receiving network device (201) and external devices, ensuring that data is transmitted and received. Additionally, the I / O interface (207) can facilitate integration between the IMS receiving network device (201) and other network components, thereby enhancing the ability to authorize and authenticate third-party user identities in an IMS session.

[0059] The IMS session controller (209) communicates with the I / O interface (207) and memory (205) to authorize and authenticate a third-party user identity in the IMS session. The IMS session controller (209) may be innovative hardware realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0060] The IMS session control unit (209) may receive an INVITE message containing signed third-party user identity information from the IMS sending network device (101). This INVITE message is typically formatted according to Session Initiation Protocol (SIP) standards to ensure compatibility between various network components. The signed third-party user identity information may be encapsulated within a security token, and the security token may use encryption algorithms such as RSA or ECC to ensure the integrity and authenticity of the information. Furthermore, the IMS session control unit (209) may send a verification request message containing the signed third-party user identity information to a verification server. The verification server may be equipped with a public key infrastructure (PKI) that enables decryption and authentication of the signature, thereby ensuring that the identity information has not been tampered with during transmission.

[0061] Furthermore, the IMS session control unit (209) may receive the result of the verification of signed third-party user identity information from the verification server. The result may be successful or unsuccessful depending on whether the signature matches the expected encryption parameters. Additionally, upon successful verification of the signed third-party user identity information, the IMS session control unit (209) may transmit an INVITE message containing the verified third-party user identity information to the receiving UE. This transmission may involve additional security measures, such as Transport Layer Security (TLS), to protect the data during transmission.

[0062] Additionally, the IMS session control unit (209) may reject an INVITE message request by providing an appropriate response containing a reason for rejection to the IMS sending network device (101) upon failed verification of signed third-party user identity information. The reason for rejection may be selected from a predefined set of SIP response codes, such as 403 (Forbidden) or 488 (Not Acceptable Here), to provide clear feedback to the IMS sending network device (101).

[0063] FIG. 3 is a flowchart illustrating a method for authorizing and authenticating a third-party user identity in an IMS session by an IMS sending network device according to one embodiment of the present disclosure.

[0064] In block 301, the method may include the step of receiving a call setup message from a UE during an IMS session. The call setup message may include initial signaling information required to establish a session, such as the UE's identity and requested service parameters. The IMS sending network device (101) may process this message to initiate an authentication sequence to ensure that the UE's request is consistent with network policies and security protocols.

[0065] In block 303, the method may include the step of retrieving UE subscription information from the HSS. By accessing the HSS, the IMS sending network device (101) can verify the UE's subscription status and determine applicable service conditions.

[0066] In block 305, the method may include a step of determining whether the UE is authorized to use third-party user identity information based on subscription information. For example, the IMS sending network device (101) may determine whether the parameter for using third-party user identity information is enabled or disabled in the subscription information. This may involve checking specific flags or attributes within the subscription profile that indicate the UE's permission regarding the use of third-party user identity. The determination logic may also consider additional factors, such as the UE's current service context or any applicable regulatory requirements.

[0067] In block 307, the method may include the step of retrieving third-party user identity information from the HSS when the UE is successfully authorized to use third-party user identity information. The UE may be successfully authorized if the parameter for using third-party user identity information is enabled in the subscription information. However, if the parameter for using third-party user identity information is disabled, the UE may be referred to as not successfully authorized, and a call request message received from the UE may be rejected. In the case of successful authorization, the retrieved third-party user identity information may be securely stored and prepared to be included in subsequent signaling messages. This may ensure that the identity information is protected from unauthorized access or tampering during transmission.

[0068] In block 309, the method may include the step of transmitting an INVITE message containing signed third-party user identity information to an IMS receiving network device (201). The signing process may involve applying a digital signature to the third-party user identity information, which provides a cryptographic guarantee of its authenticity and integrity. The IMS receiving network device may then verify the signature to confirm that the identity information has not been altered and that use by the sending UE has actually been authorized.

[0069] FIG. 4 is a flowchart illustrating a method for authorizing and authenticating a third-party user identity in an IMS session using an IMS receiving network device according to one embodiment of the present disclosure.

[0070] In block 401, the method may include the step of receiving an INVITE message containing signed third-party user identity information from an IMS sending network device (101). The signed third-party user identity information may typically be encapsulated within a SIP header, such as a P-Asserted-Identity or From header, and may be digitally signed using a private key associated with the third-party user identity provider. This can ensure the integrity and authenticity of the identity information as it passes through the network. The IMS sending network device may also include additional metadata, such as a timestamp or nonce, to prevent replay attacks.

[0071] In block 403, the method may include the step of transmitting a verification request message containing signed third-party user identity information to a verification server to verify the signed third-party user identity information. The verification server, often referred to as a Secure Telephone Identity-Verification Service (STI-VS), may verify digital signatures using PKI. It may check the signature of a trusted certificate authority (CA) to ensure that the identity information has not been tampered with. The verification process may also include checking the certificate revocation status to ensure that the signed certificate remains valid.

[0072] In Block 405, this method may include the step of receiving a verification result of signed third-party user identity information from a verification server. The result may be success or failure. A successful verification may indicate that the signature is valid and the identity information is authentic, whereas an unsuccessful verification may trigger additional security measures, such as logging events for further analysis. The verification server may also provide additional information, such as the identity of the certificate authority that issued the signing certificate, to assist in the decision-making process.

[0073] In block 407, the method may include the step of transmitting an INVITE message containing verified third-party user identity information to a receiving UE upon successful verification of signed third-party user identity information. The IMS receiving network device (201) may also include additional headers or parameters within the INVITE message to indicate successful verification to the receiving UE. This may ensure that the receiving UE trusts the identity information and can proceed with session establishment. The transmission may also include updating session state information to reflect successful verification.

[0074] In block 409, the method may include the step of rejecting an INVITE message request by providing an appropriate response having a rejection cause code to the IMS sending network device (101) upon unsuccessful verification of signed third-party user identity information. The rejection cause code may typically be a SIP response code, such as 403 Forbidden, indicating that the request is not authorized. The IMS receiving network device may also include additional diagnostic information in the response to aid in troubleshooting and resolution. This rejection process can help maintain the security and integrity of the IMS network by preventing unauthorized access.

[0075] FIG. 5a is a block diagram of an HSS for performing authorization and authentication of a third-party user identity in an IMS session according to one embodiment of the present disclosure.

[0076] The HSS (501) may include a processor (503), memory (505), an I / O interface (507), and an IMS session controller (509). Additionally, the processor (503) of the HSS (501) may communicate with the memory (505), the I / O interface (507), and the IMS session controller (509). The processor (503) may be configured to execute instructions stored in the memory (505) and perform various processes. The processor (503) may include one or more processors, such as a general-purpose processor, e.g., a central processing unit (CPU), an application processor (AP), a graphics-dedicated processing unit, e.g., a graphics processing unit (GPU), a visual processing unit (VPU), and / or an artificial intelligence (AI)-dedicated processor, e.g., a neural processing unit (NPU).

[0077] Additionally, the memory (505) of the HSS (501) may include storage locations that can be addressed via the processor (503). The memory (505) is not limited to volatile or non-volatile memory and may include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical disks, floppy disks, flash memory, EPROM, or EEPROM memory may also be included in the memory (505). Additionally, the memory (505) of the HSS (501) may store various information received from a third party. The various information may include third-party user identity information and third-party user identity information usage parameters.

[0078] The I / O interface (507) can transmit information between external peripheral devices, which are input / output devices associated with the memory (505) and the HSS (501). The I / O interface (507) can receive various information from third-party devices.

[0079] The IMS session controller (509) communicates with the I / O interface (507) and memory (505) to authorize and authenticate a third-party user identity in the IMS session. The IMS session controller (509) may be innovative hardware realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0080] The IMS session control unit (509) can receive third-party user identity information from a third-party device (613) via the HSS (501). The third party may be at least one of a trusted application function or an untrusted application function. Additionally, the IMS session control unit (509) can store the third-party user identity information and third-party user identity information usage parameters received from the third-party device (613). Additionally, if the third-party device (613) is an untrusted application function, the IMS session control unit (509) can receive the third-party user identity information and third-party user identity information usage parameters through a Network Exposure Function (NEF) (803). Additionally, the IMS session control unit (509) can directly receive third-party user identity information usage parameters and third-party user identity information from the third-party device (613) when the third-party is a trusted application function.

[0081] FIG. 5b is a flowchart illustrating a method for authorizing and authenticating a third-party user identity in an IMS session by an HSS according to one embodiment of the present disclosure.

[0082] In block 511, the method may include the step of receiving third-party user identity information usage parameters and third-party user identity information from a third-party device (613). The third party may be a trusted application function or an untrusted application function, but is not limited thereto. The usage parameters may specify conditions or restrictions under which the third-party user identity may be used, such as time zone restrictions or specific service types. This information may ensure that the third-party user identity is used in compliance with policy and regulatory requirements.

[0083] In block 513, the method may include the step of storing third-party user identity information usage parameters and third-party user identity information received from a third-party device (613). The Home Subscriber Server (HSS) (501) may maintain this information in a secure database to ensure that this information is accessible for future authorization checks. The storage process may include encrypting the data to protect it from unauthorized access and ensuring that the data is replicated across multiple nodes for redundancy and reliability.

[0084] In one embodiment, if the third-party device (613) is an untrusted application function, the HSS (501) may receive third-party user identity information usage parameters and third-party user identity information through the NEF (803). The NEF (803) may act as a security gateway to provide a controlled interface for untrusted applications to interact with the HSS (501). It may also perform additional verification checks to ensure that the information being provided conforms to legitimate and expected formats.

[0085] Additionally, if the third-party device (613) is a trusted application function, the HSS (501) can receive third-party user identity information usage parameters and third-party user identity information through the trusted application function. The trusted application function can have a direct interface with the HSS (501), enabling more efficient and streamlined communication. This setup ensures that the trusted application can update identity information quickly and securely as needed.

[0086] FIG. 6 is a sequence diagram illustrating the authorization and authentication process of a third-party user identity in an IMS session according to one embodiment of the present disclosure.

[0087] In step S1, the third-party device (613) may provision a list of IMPUs to the HSS (501) along with a third-party user identity common to all IMPUs. If the IMPUs use unique third-party identities different for each IMPU, this information will be shared with the telecommunications carrier by the third-party device (613). Additionally, the telecommunications carrier will provision a subscription profile for each IMPU within the HSS (501). The provisioning process may involve the use of a secure API or interface to ensure that data is transmitted and stored securely. The telecommunications carrier may also perform additional checks to verify the accuracy and completeness of the information being provisioned.

[0088] At step S2, it is assumed that UE1 (601) may already be registered with the OS-CSCF (101) (the OS-CSCF is used interchangeably as an IMS outgoing network device). The registration process may involve UE1 (601) authenticating itself to the IMS network using credentials, such as a username and password or a SIM-based authentication mechanism. Once registered, UE1 (601) may be assigned a unique session identifier used to track and manage interactions with the network.

[0089] In step S3, UE1 (601) may initiate an IMS session with the OS-CSCF (101) in a call request message by sending an INVITE with UE2 (615) to make a call. The INVITE message may include various headers and parameters specifying details of the call, such as the codec to be used, the quality of service, and the requested service or any additional features. The OS-CSCF may process this information to determine the appropriate routing and processing of the call request.

[0090] In step S4, the OS-CSCF (101) may download the IMPU subscription information from the HSS (501). This information may include details such as the user's service rights, any applicable usage restrictions, and the current status of the user's subscription. The OS-CSCF (101) may use this information to ensure that the call request complies with the user's subscription terms and conditions.

[0091] At step S5, the OS-CSCF (101) can check subscription information to determine whether the user associated with UE1 (601) is authorized to use third-party user identity services. For example, the OS-CSCF (101) can check subscription information to verify the use of third-party identity. If the third-party user identity information use parameter is enabled, the OS-CSCF (101) can extract third-party user identity information from the PAI / From / Call-Info header and verify it by comparing it with the third-party identities stored for IMPUs within the subscription profile.

[0092] In step S6, upon a successful match, the OS-CSCF (101) may call the signature server (STI-AS) (605). The OS-CSCF (101) may retrieve the signature server address from the subscription information. The signature server is responsible for generating a digital signature for the third-party user identity information, thereby ensuring its integrity and authenticity when the third-party user identity information is transmitted over the network.

[0093] In step S7, the signing server (605), after receiving the INVITE from the IMS sending network device / OS-CSCF (101), may add an identity header in accordance with TS 24.229 and sign it. The identity header may include signed third-party user identity information along with any additional metadata required for verification. The signing server (605) may also include a timestamp or other information to prevent replay attacks and ensure the freshness of the signature. The signing server (605) may forward the INVITE back to the OS-CSCF (101).

[0094] In step S8, the OS-CSCF (101) can forward the INVITE to an IMS receiving network device / TS-CSCF (201) (hereinafter, TS-CSCF is used interchangeably). The forwarding process involves routing the INVITE message through the IMS network to ensure that the INVITE message reaches the correct receiving network device. The OS-CSCF (101) can also perform additional checks to ensure that the INVITE message is complete and correctly formatted before forwarding the INVITE message.

[0095] At step S9, the TS-CSCF (201) of the receiving side will call the verification server / STI-VS (609) based on the presence of the identity header and forward the INVITE request to the STI-VS (609). The verification server is responsible for verifying the digital signature on the identity header to ensure that the third-party user identity information is authentic and has not been tampered with. The verification process may include checking the signature against a trusted certificate authority and verifying the revocation status of the certificate.

[0096] In step S10, the verification server (609) verifies the identity header using the certificate and provides the validity status to the TS-CSCF (201) along with the INVITE. The validity status may indicate whether the signature is valid and whether the identity information is authentic. To assist in the decision-making process, the verification server (609) may also provide additional information, such as the identity of the certificate authority that issued the signature certificate.

[0097] In step S11, the receiving side TS-CSCF (201) may send an INVITE toward UE2 (615) based on a successful acknowledgment result. Additionally, the TS-CSCF (201) may reject the call for a failed result received from the verification server (609). The TS-CSCF (201) may include additional headers or parameters in the INVITE message to indicate a successful acknowledgment to the receiving UE (615). This ensures that the receiving UE (615) can trust the identity information and proceed with session establishment.

[0098] In step S12, a successful call may occur between UE1 (601) and UE2 (615). The call setup process may include establishing a media path between the two UEs, negotiating codecs and quality of service parameters, and exchanging any additional information required for the call. The IMS network can ensure that the call is routed efficiently and securely, thereby providing users with a high-quality communication experience.

[0099] FIG. 7 is a sequence diagram illustrating the signing and verification process of third-party user identity information in an IMS according to one embodiment of the present disclosure.

[0100] In step A1, UE1 (601) can send a SIP INVITE message to the IMS sending network device (101) to initiate a call with UE2 (615).

[0101] In step A2, the IMS sending network device (101) can determine whether UE1 (601) is authorized to use third-party user identity information based on subscription information. The subscription information may be downloaded from the HSS (501) by the IMS sending network device (101). The subscription information may include a third-party user identity information usage parameter indicating whether UE1 (601) is authorized to use third-party user identity information or not. In particular, if the third-party user identity information usage parameter is enabled or set to 1, UE1 (601) may be authorized. However, if the third-party user identity information usage parameter is disabled or set to 0, UE1 (601) may not be authorized to use third-party user identity information.

[0102] In step A3, upon successful authorization, the IMS sending network device (101) can retrieve RCD information, an RCD URL, or an RCD server address from the HSS (501).

[0103] In step A4, the IMS sending network device (101) may receive RCD information (hereinafter, RCD information is used interchangeably with third-party user identity information), an RCD URL, or an RCD server address.

[0104] In step A5, the IMS sending network device (101) can retrieve RCD information from the RCD server (701) using an RCD URL or RCD server address, a sending IMPU, or a wildcarded IMPU. The retrieval process may include accessing external servers or databases where RCD information is stored using secure communication protocols to ensure data confidentiality. The use of an IMPU or a wildcarded IMPU enables flexible and efficient retrieval of RCD information by accommodating various user scenarios and network settings.

[0105] In step A6, the IMS sending network device (101) may request RCD information or an RCD URL from the AS for signing (605). The signing process may include cryptographic operations that generate a digital signature that serves as proof of authenticity and integrity for the RCD information.

[0106] In step A7, the IMS sending network device (101) may receive signed RCD information or a signed RCD URL. For example, the signing AS (605) may return a Personalized Authentication Secure Signature Protocol (PASSP) or a Trusted Token (T / Token) to the IMS sending network device (101). The signed data may then be securely stored within the network device, ready to be included in subsequent communication messages. The receipt of the signed information indicates the completion of the signing process, which may allow the network device to proceed with sending an INVITE message to the IMS receiving network device (201).

[0107] In step A8, the IMS sending network device (101) may transmit a SIP INVITE message having signed RCD information or a signed RCD URL to the IMS receiving network device (201). The inclusion of signed RCD information within the INVITE message may provide the receiving network with data to verify the authenticity of the communication session.

[0108] In step A9, the IMS receiving network device (201) may call a request for a signed RCD URL or an AS (609) for verification of the signed RCD information. The verification process may include checking the digital signature of the original RCD information using an encryption algorithm to approve the integrity and authenticity of the data.

[0109] In step A10, the verification AS (609) may transmit the verification result of the signed RCD URL or signed RCD information to the IMS receiving network device (201). The result or status of the verification may be successful or unsuccessful. Successful verification may indicate that the RCD information is authentic and has not been tampered with, thereby allowing the communication session to proceed. Additionally, unsuccessful verification may trigger security measures, such as rejecting the session or sending an alert to the network administrator.

[0110] In step A11, if the verification status is successful, the IMS receiving network device (201) may send a SIP INVITE message to UE2 (615) along with verified RCD information or an RCD URL. Inclusion of verified RCD information within the INVITE message may provide UE2 (615) with data to establish a secure and trusted communication session.

[0111] In step A12, UE2 (615) can retrieve RCD information from the RCD server (701) using an RCD URL. The retrieval process involves accessing the RCD server (701) using secure communication protocols, thereby ensuring the confidentiality and integrity of the data. The RCD information can provide UE2 (615) with enhanced communication capabilities, such as sender identification and multimedia content sharing, thereby improving the overall user experience.

[0112] FIG. 8 is a sequence diagram illustrating the process of provisioning IMS user-specific attributes according to one embodiment of the present disclosure.

[0113] In step B1, the Application Function (AF) (805) may provision third-party user identity information for an IMS user to the NEF (803), for example, if the AF (805) is an untrusted AF (805). The provisioning process may include securely transmitting the third-party user identity information from the AF (805) to the NEF (803) using encryption and authentication mechanisms to ensure data confidentiality and integrity. The NEF (803) may act as an intermediary by facilitating the secure exchange of information between the AF (805) and other network entities.

[0114] In step B2, the NEF (803) may forward third-party user identity information for the IMS user to the IMS AS (801). The forwarding process may involve transmitting information securely from the NEF (803) to the IMS AS (801) using secure communication protocols to ensure data confidentiality and integrity. The IMS AS (801) may be responsible for processing and verifying the third-party user identity information.

[0115] In step B3, the IMS AS (801) can verify the third-party user identity information received from the NEF (803). The IMS AS (801) can also perform additional checks, such as verifying the authenticity of the information and ensuring that the information has not been tampered with.

[0116] In step B4, the IMS AS (801) may store the IMS user's third-party user identity information in the HSS (501) upon successful verification. The storage process may involve securely transmitting the information from the IMS AS (801) to the HSS (501) using encryption and authentication mechanisms to ensure data confidentiality and integrity. The HSS (501) may serve as a central repository for storing the third-party user identity information along with other user-specific attributes.

[0117] In one embodiment, AF (805) may directly provision third-party user identity information to HSS (501). This direct provisioning process may involve bypassing NEF (803) and IMS AS (801) to securely transmit information from AF (805) to HSS (501).

[0118] In one embodiment, AF (805) may directly provision third-party user identity information to HSS (501) via NEF (803). This approach may involve transmitting the information securely from AF (805) to NEF (803), and then from NEF (803) to HSS (501). Therefore, the proposed solution provides an additional layer of security because NEF (803) can perform checks and verifications before forwarding the information to HSS (501).

[0119] In one embodiment, the objectives are achieved by providing a method for authorizing and authenticating a third-party user identity in an IP multimedia subsystem (IMS) session. In this context, the third-party user is a user belonging to a third-party network, which may be, for example, an enterprise or private network. The method may include the step of an IMS sending network device receiving a call setup message from a UE during the IMS session. The method may include the step of the IMS sending network device retrieving the UE's subscription information from a home subscriber server (HSS). The method may include the step of the IMS sending network device determining whether the UE is authorized to use third-party user identity information based on the subscription information. The method may include the step of the IMS sending network device retrieving the third-party user identity information from the HSS based on the determination that the UE is authorized to use the third-party user identity information. The above method may include the step of rejecting the call setup message received from the UE (601) by the IMS sending network device based on a determination that the UE (601) is not authorized to use the third-party user identity information. The above method may include the step of transmitting an INVITE message containing signed third-party information to the IMS receiving network device by the IMS sending network device.

[0120] In one embodiment, in the method, the IMS sending network device may be at least one of a serving-call session control function (S-CSCF) or an IMS application server (AS).

[0121] In one embodiment, the step of determining whether the UE is authorized to use third-party user identity information in the method may include the step of determining by the IMS sending network device whether a parameter for using third-party user identity information in the subscriber information for the UE is enabled or disabled. In the method, the step of determining whether the UE is authorized to use third-party user identity information may include the step of determining by the IMS sending network device whether the UE is authorized to use the third-party user identity information when the parameter for using third-party user identity information is enabled. In the method, the step of determining whether the UE is authorized to use third-party user identity information may include the step of determining by the IMS sending network device that the UE is not authorized to use the third-party user identity information when the use of third-party user identity information is disabled.

[0122] In one embodiment, in the method, the third party information may include at least one of email information, sender name, organization information, and job title information per IMPU or per IMPU group.

[0123] In one embodiment, the step of transmitting the INVITE message containing the signed third-party information to the IMS receiving network device in the method may include the step of transmitting the INVITE message to a signing server by the IMS sending network device to sign the third-party user identity information. In the method, the step of transmitting the INVITE message containing the signed third-party information to the IMS receiving network device may include the step of receiving the signed third-party information from the signing server by the IMS sending network device. In the method, the step of transmitting the INVITE message containing the signed third-party information to the IMS receiving network device may include the step of transmitting the INVITE message containing the signed third-party information to the IMS receiving network device by the IMS sending network device.

[0124] In one embodiment, the objectives are achieved by providing a method for authorizing and authenticating a third-party user identity in an IMS session. The method may include the step of receiving, by an IMS receiving network device, an INVITE message containing signed third-party user identity information from an IMS sending network device. The method may include the step of transmitting a verification request message containing the signed third-party user identity information to a verification server by the IMS receiving network device. The method may include the step of receiving a verification result of the signed third-party user identity information from the verification server by the IMS receiving network device. The result may be success or failure. The method may include the step of transmitting an INVITE message containing the verified third-party user identity information to a receiving UE upon successful verification of the signed third-party user identity information. The above method may include the step of rejecting the INVITE message request by providing the IMS sending network device with an appropriate response having a rejection cause code upon successful verification of the signed third-party user identity information.

[0125] In one embodiment, in the method, the IMS receiving network device may be at least one of S-CSCF or IMS AS.

[0126] In one embodiment, the objectives are achieved by providing a method for authorizing and authenticating a third-party user identity in an IMS session. The method may include the step of receiving third-party user identity information and third-party user identity information usage parameters from a third-party device via an HSS. The value of the third-party user identity information usage parameter may indicate whether the sending side is authorized to use the third-party user identity during the IMS session. The third party may be at least one of a trusted application function or an untrusted application function. The method may include the step of storing the third-party user identity information and third-party user identity information usage parameters received from the third-party device via the HSS.

[0127] In one embodiment, in the method, the step of receiving third-party user identity information from the third-party device may include, if the third-party device is the untrusted application function, receiving the third-party user identity information and third-party user identity information usage parameters via the HSS through the NEF. In the method, the step of receiving third-party user identity information from the third-party device may include, if the third-party device is the trusted application function, receiving the third-party user identity information and third-party user identity information usage parameters directly from the third-party device via the HSS.

[0128] In one embodiment, the method may include the step of receiving third-party user identity information and third-party user identity information usage parameters by the HSS, for each IMPU or for each group of IMPUs.

[0129] In one embodiment, objectives are achieved by providing an IMS sending network device for authorizing and authenticating third-party user identities in an IP multimedia subsystem session. The IMS sending network device may include a processor and an IMS session control unit connected to the processor for communication. The IMS session control unit may receive a call setup message from a UE during the IMS session. The IMS session control unit may retrieve the UE's subscription information from an HSS. Based on the subscription information, the IMS session control unit may determine whether the UE is authorized to use third-party user identity information. If the UE is successfully authorized to use the third-party user identity information, the IMS session control unit may retrieve the third-party user identity information from the HSS. The IMS session control unit may transmit an INVITE message containing signed third-party information to an IMS receiving network device.

[0130] In one embodiment, objectives are achieved by providing an IMS receiving network device for authorizing and authenticating third-party identities in an IP multimedia subsystem session. The IMS receiving network device may include a processor and an IMS session control unit connected to communicate with the processor. The IMS session control unit may receive an INVITE message containing signed third-party user identity information from an IMS sending network device. The IMS session control unit may transmit a verification request message containing the signed third-party user identity information to a verification server. The IMS session control unit may receive a verification result of the signed third-party user identity information from the verification server, and the result may be success or failure. Upon successful verification of the signed third-party user identity information, the IMS session control unit may transmit an INVITE message containing the verified third-party user identity information to a receiving UE. The above IMS session control unit can reject the INVITE message request by providing the IMS sending network device with an appropriate response having a rejection cause code upon successful verification of the above signed third-party user identity information.

[0131] In one embodiment, objectives are achieved by providing a Home Subscriber Server (HSS) for authorizing and authenticating third-party identifiers in an IP multimedia subsystem session. The HSS may include a processor and an IMS session control unit connected to the processor to enable communication. The IMS session control unit may receive third-party user identity information and third-party user identity information usage parameters from a third-party device, wherein the third-party is at least one of a trusted application function or an untrusted application function. The IMS session control unit may store the third-party user identity information and third-party user identity information usage parameters received from the third-party device.

[0132] In one embodiment, a method is provided for authorization and authentication of a third-party user identity within an IP multimedia subsystem (IMS) by an outgoing IMS network.

[0133] In one embodiment, in the method, the sending IMS network may include at least one of a serving-call session control function (S-CSCF) or an IMS application server (AS).

[0134] In one embodiment, the method, wherein the step of identifying whether the UE is authorized to use the third-party user identity may include the step of identifying whether a third-party user identity usage parameter in the subscription information for the UE is activated. In the method, the step of identifying whether the UE is authorized to use the third-party user identity may include the step of determining that the UE is authorized to use the third-party user identity when the third-party user identity usage parameter is activated.

[0135] In one embodiment, in the method, the third-party user identity may include at least one of a job title, a sender name, an email address, and organizational information per IMPU or a wildcard-processed IMPU.

[0136] In one embodiment, the step of transmitting the INVITE containing the signed third-party user identity to the receiving IMS network device in the method may include the step of transmitting the INVITE to a signing server to sign the third-party user identity. In the method, the step of transmitting the INVITE containing the signed third-party user identity to the receiving IMS network device may include the step of receiving the signed third-party user identity from the signing server. In the method, the step of transmitting the INVITE containing the signed third-party user identity to the receiving IMS network device may include the step of transmitting the INVITE containing the signed third-party user identity to the receiving IMS network.

[0137] In one embodiment, the method may include the step of rejecting the INVITE received from the UE based on a determination that the UE is not authorized to use the third-party user identity.

[0138] In one embodiment, a method is provided for authorization and authentication of a third-party user identity within an IP multimedia subsystem (IMS) by a receiving IMS network.

[0139] In one embodiment, in the method, the receiving IMS network may include at least one of an S-CSCF or an IMS AS.

[0140] In one embodiment, the method, wherein the step of receiving the third-party user identity from the third-party device may include receiving the third-party user identity and the third-party user identity usage parameters through a network exposure function (NEF) when the third-party device is the untrusted application function. In the method, wherein the step of receiving the third-party user identity from the third-party device may include receiving the third-party user identity usage parameters and the third-party user identity directly from the third-party device when the third-party device is the trusted application function.

[0141] In one embodiment, the method may include the step of receiving the third-party user identity and the third-party user identity usage parameters for each IMPU or wildcard-processed IMPU.

[0142] The foregoing description of specific embodiments will sufficiently reveal the general nature of the embodiments of this disclosure so that others can easily modify and / or adapt these specific embodiments for various applications without departing from the general concept. Accordingly, such modifications and alterations are intended to be understood within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that the language or terms used in this disclosure are for descriptive purposes only and are not limiting. Therefore, although the embodiments in this specification have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments of this disclosure may be modified and practiced within the scope of the embodiments as described in this disclosure.

Claims

Claim 1 A method performed by an originating IMS network for the authorization and authentication of a third-party user identity in an IP Multimedia Subsystem (IMS), comprising: receiving an invitite from a User Equipment (UE); obtaining subscription information of the UE from a Home Subscriber Server (HSS); identifying whether the UE is authorized to use the third-party user identity based on the subscription information; obtaining the third-party user identity from the HSS based on identifying whether the UE is authorized to use the third-party user identity; and transmitting the invitite containing the signed third-party user identity to a terminating IMS network. Claim 2 The method of claim 1, wherein the sending IMS network comprises at least one of a Serving-Call Session Control Function (S-CSCF) or an IMS Application Server (AS). Claim 3 The method of claim 1, wherein the step of identifying whether the UE is authorized to use the third-party user identity comprises: identifying whether a third-party user identity usage parameter in the subscription information for the UE is activated; and determining that the UE is authorized to use the third-party user identity if the third-party user identity usage parameter is activated. Claim 4 In claim 1, the method wherein the third-party user identity comprises at least one of an IMPU or wildcarded IMPU-specific job title, sender name, email address, and organization information. Claim 5 A method according to claim 1, wherein the step of transmitting the INVITE containing the signed third-party user identity to the receiving IMS network device comprises: transmitting the INVITE to a signing server to sign the third-party user identity; receiving the signed third-party user identity from the signing server; and transmitting the INVITE containing the signed third-party user identity to the receiving IMS network. Claim 6 A method according to claim 1, comprising the step of rejecting the INVITE received from the UE based on a determination that the UE is not authorized to use the third-party user identity. Claim 7 A method performed by a terminating IMS network for the authorization and authentication of a third-party user identity in an IP Multimedia Subsystem (IMS), comprising: receiving an INVITE containing a signed third-party user identity from an originating IMS network; transmitting said INVITE containing the signed third-party user identity to a verification server; receiving a verification result of said signed third-party user identity from said verification server, wherein the result may be successful or unsuccessful; and transmitting an INVITE containing a verified third-party user identity to a receiving UE based on the successful verification of said signed third-party user identity. Claim 8 In claim 7, the receiving IMS network comprises at least one of a Serving-Call Session Control Function (S-CSCF) or an IMS Application Server (AS). Claim 9 A method performed by a home subscriber server (HSS) for the authorization and authentication of a third-party user identity in an IP Multimedia Subsystem (IMS), comprising the step of receiving the third-party user identity and third-party user identity usage parameters from a third-party device, wherein the third-party is at least one of a trusted application function or an untrusted application function; and the step of storing the third-party user identity and third-party user identity usage parameters received from the third-party device. Claim 10 In claim 9, the step of receiving the third-party user identity from the third-party device comprises: receiving the third-party user identity and the third-party user identity usage parameters through a Network Exposure Function (NEF) when the third-party device is an untrusted application function; and receiving the third-party user identity and the third-party user identity usage parameters directly from the third-party device when the third-party device is a trusted application function. Claim 11 A method according to claim 9, comprising the step of receiving the third-party user identity and the third-party user identity usage parameters for each IMPU or wildcarded IMPU. Claim 12 An originating IMS network device for the authorization and authentication of a third-party user identity in an IP Multimedia Subsystem (IMS), comprising: a processor; and an IMS session control unit connected to communicate with the processor, wherein the IMS session control unit receives an invitite from a User Equipment (UE); obtains subscription information of the UE from a Home Subscriber Server (HSS); identifies whether the UE is authorized to use the third-party user identity based on the subscription information; obtains the third-party user identity from the HSS based on identifying that the UE is authorized to use the third-party user identity; and transmits the invitite containing the signed third-party user identity to a terminating IMS network device. Claim 13 A terminating IMS network device for authorization and authentication of a third-party user identity in an IP Multimedia Subsystem (IMS), comprising: a processor; and an IMS session control unit connected to communicate with said processor, wherein the IMS session control unit receives an INVITE containing a signed third-party user identity from an originating IMS network device; transmits said INVITE containing the signed third-party user identity to a verification server; receives a verification result of said signed third-party user identity from said verification server, said result may be successful or unsuccessful; and transmits an INVITE containing a verified third-party user identity to a receiving UE based on the successful verification of said signed third-party user identity information. Claim 14 A home subscriber server (HSS) for the authorization and authentication of a third-party user identity in an IP Multimedia Subsystem (IMS), comprising: a processor; and an IMS session controller connected to communicate with said processor, wherein the IMS session controller receives said third-party user identity and said third-party user identity usage parameters from said third-party device, said third-party is at least one of a trusted application function or an untrusted application function; and the HSS stores said third-party user identity and said third-party user identity usage parameters received from said third-party device.

Images