indicating the source of the ims session setup request

Abstract

Example embodiments of this disclosure relate to solutions for indicating the source of an IP Multimedia Subsystem (IMS) session establishment request. In one solution, an apparatus receives a request for establishing an IMS session from a network entity. The request indicates whether the initiator of the request is from the network side, a third party, or a user equipment, and may indicate the data channel application used. Based on the initiator or the data channel application used, the apparatus determines acceptance information regarding the establishment of the IMS session. This acceptance information indicates whether the apparatus accepts the establishment of the IMS session.

Description

Technical Field

[0001] Various exemplary embodiments of this disclosure generally relate to the telecommunications field, and more particularly to methods, apparatus, devices, and computer-readable storage media for indicating the source of an IP Multimedia Subsystem (IMS) session establishment request. Background Technology

[0002] A communication network can be used as a facility to enable communication between two or more communication devices or to provide communication devices with access to a data network. A mobile or wireless communication network is an example of a communication network. Services can be provided to communication devices by an application server.

[0003] Communication networks can operate according to standards provided by organizations such as the 3rd Generation Partnership Project (3GPP) or the European Telecommunications Standards Institute (ETSI). Examples of standards provided by 3GPP are the so-called 3GPP standards for cellular technologies, such as those for 4G, 5G, and 6G technologies. Summary of the Invention

[0004] In a first aspect of this disclosure, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive from a network entity a request for the establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that the initiator of the request is from the network side, a third party, or a user equipment; and determine acceptance information regarding the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.

[0005] In a second aspect of this disclosure, a network entity is provided. The network entity includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: determine that the establishment of an IP Multimedia Subsystem (IMS) session with the device is initiated from a network side, a third party, or a user equipment; and transmit to the device a request for the establishment of the IMS session, the request indicating that the initiator of the request is from a network side, a third party, or a user equipment.

[0006] In a third aspect of this disclosure, a method is provided. The method includes: receiving from a network entity a request for the establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that the initiator of the request is from a network side, a third party, or a user equipment; and determining acceptance information regarding the establishment of the IMS session based on the initiator, the acceptance information indicating whether a device accepts the establishment of the IMS session.

[0007] In a fourth aspect of this disclosure, a method is provided. The method includes: determining that the establishment of an IP Multimedia Subsystem (IMS) session with the device is initiated from a network side, a third party, or a user equipment; and transmitting to the device a request for the establishment of the IMS session, the request indicating that the initiator of the request is from a network side, a third party, or a user equipment.

[0008] In a fifth aspect of this disclosure, an apparatus is provided. The apparatus includes: components for receiving from a network entity a request for establishing an IP Multimedia Subsystem (IMS) session, the request indicating that the initiator of the request is from a network side, a third party, or a user equipment; and components for determining acceptance information regarding the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.

[0009] In a sixth aspect of this disclosure, a network entity is provided. The network entity includes: components for determining whether the establishment of an IP Multimedia Subsystem (IMS) session with the device is initiated from a network side, a third party, or a user equipment; and components for transmitting a request to the device for the establishment of the IMS session, the request indicating that the initiator of the request is from a network side, a third party, or a user equipment.

[0010] In a seventh aspect of this disclosure, a computer-readable medium is provided. The computer-readable medium includes instructions stored thereon for causing a device to perform at least the method according to a third aspect.

[0011] In an eighth aspect of this disclosure, a computer-readable medium is provided. The computer-readable medium includes instructions stored thereon for causing a device to perform at least the method according to the fourth aspect.

[0012] It should be understood that the summary portion is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] Some exemplary embodiments will now be described with reference to the accompanying drawings, in which: Figure 1 An example communication environment 100 in which example embodiments of the present disclosure may be implemented is shown; Figure 2 The signaling diagram of an example IMS session with a network-initiated peer-to-peer (P2P) application data channel (ADC) is shown. Figure 3 A signaling diagram for indicating the source of an establishment request is shown according to some example embodiments of the present disclosure; Figure 4The signaling diagram of an example IMS session between two UEs and a P2P DC according to some example embodiments of the present disclosure is shown. Figure 5 The diagram illustrates a signaling diagram for verifying user consent to a P2P ADC establishment request initiated by a data channel (DC) application server (AS) according to some example embodiments of the present disclosure; Figure 6 A flowchart is shown illustrating a method implemented at a device according to some example embodiments of the present disclosure; Figure 7 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 8 A simplified block diagram of a device suitable for implementing example embodiments of the present disclosure is shown; and Figure 9 A block diagram of an example computer-readable medium according to some example embodiments of the present disclosure is shown.

[0014] In all the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0015] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and to assist those skilled in the art in understanding and implementing this disclosure, without imposing any limitation on the scope of this disclosure. The embodiments described herein can be implemented in various ways other than those described below.

[0016] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0017] References to "an embodiment," "embodiment," "example embodiment," etc., in this disclosure indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment needs to include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, whether explicitly described or not, it is believed that its influence on such feature, structure, or characteristic in conjunction with other embodiments is within the knowledge of those skilled in the art.

[0018] It should be understood that although various elements may be described herein using the preceding terms such as "first," "second," etc., these elements should not be limited by these terms. These terms are used only to distinguish one element from another, and they do not restrict the order of the terms. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0019] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements is connected by “and” or “or”, means at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

[0020] As used herein, unless explicitly stated otherwise, the execution step “in response to A” does not indicate that the step is performed immediately after “A” occurs, and may include one or more intermediate steps.

[0021] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that the terms “comprising,” “including,” “having,” “containing,” and / or “comprising” as used herein specify the presence of the stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0022] As used in this application, the term "circuit system" may refer to one or more of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuits only), and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and (ii) Any portion of a hardware processor(s) having software (including (multiple) digital signal processors), software, and (multiple) memories, which work together to enable a device (such as a mobile phone or server) to perform various functions, and (c) (multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) for operation, but the software may not exist when it is not required for operation.

[0023] This definition of circuit system applies to all uses of the term in this application (including any claims). As another example, as used in this application, the term circuit system also covers only hardware circuitry, or a processor (or multiple processors), or a portion of hardware circuitry or a processor and its (or their) accompanying software and / or firmware. For example, and if applicable to a particular claim element, the term circuit system also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or networking devices.

[0024] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generation of communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, fifth-generation (5G), 5.5G, sixth-generation (6G) communication protocols and / or any other currently known or future-developed protocols. Embodiments of this disclosure can be applied to a variety of communication systems. Given the rapid development in communications, there will naturally be future types of communication technologies and systems that can implement this disclosure. The scope of this disclosure should not be limited to the aforementioned systems only.

[0025] As used herein, the term "network device" refers to a node in a communications network through which terminal devices access the network and receive services. Network devices can refer to base stations (BS) or access points (APs), such as Node B (NodeB or NB), evolved Node B (eNodeB or eNB), NR NB (also known as gNB), Remote Radio Unit (RRU), Radio Head (RH), Remote Radio Head (RRH), repeater, Integrated Access and Backhaul (IAB) node, low-power node (such as femtoseconds, picoseconds), non-terrestrial network (NTN) or non-terrestrial network equipment (such as satellite network equipment, low Earth orbit (LEO) satellites, and geostationary Earth orbit (GEO) satellites), spacecraft network equipment, etc., depending on the terminology and technology applied. In some example embodiments, the Radio Access Network (RAN) split architecture includes a centralized unit (CU) and a distributed unit (DU) at the IAB donor node. An IAB node includes a mobile terminal (IAB-MT) portion that behaves similarly to a UE with respect to its parent node, and the DU portion of the IAB node behaves similarly to a base station with respect to the next-hop IAB node.

[0026] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not a limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices can include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop mounted equipment (LMEs), USB dongles, smart devices, wireless customer premises equipment (CPEs), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. The terminal device may also correspond to the mobile terminal (MT) portion of an IAB node (e.g., a relay node). In the following description, the terms "terminal device," "communication device," "terminal," "user equipment," and "UE" are used interchangeably.

[0027] As used herein, the terms “resource,” “transmission resource,” “resource block,” “physical resource block” (PRB), “uplink resource,” or “downlink resource” can refer to any resource used to perform communication, such as communication between a terminal device and a network device, including resources in the time domain, frequency domain, spatial domain, code domain, or any other combination of time, frequency, spatial, and / or code domain resources used to enable communication. In the following, unless explicitly stated otherwise, resources in both the frequency and time domains will be used as examples of transmission resources used to describe some exemplary embodiments of this disclosure. Note that the exemplary embodiments of this disclosure are equally applicable to other resources in other domains.

[0028] The core network functionality described herein can be implemented as a core network entity comprising a combination of hardware processing circuitry and software and / or firmware including machine-readable instructions, or software including machine-readable instructions executable by at least one processor of the hardware processing circuitry. The hardware processing circuitry includes at least one processor and at least one memory storing machine-readable instructions executable by at least one processor of the hardware processing circuitry. The processor includes any or a combination of accelerators, microprocessors, cores of multi-core microprocessors, microcontrollers, programmable integrated circuits, programmable gate arrays, digital signal processors, central processing units, graphics processing units, and tensor processing units. The memory includes any or a combination of volatile or non-volatile memory (e.g., flash memory, cache, random access memory (RAM), and / or read-only memory (ROM)). The memory stores machine-readable instructions for the software and / or firmware to be executed by at least one processor of the hardware processing circuitry. The machine-readable instructions can be executed by at least one processor of the hardware processing circuitry, causing the hardware processing circuitry to perform the actions or operations of the methods described herein. For example, the session management function described herein can be implemented as a session management entity, and the session management policy control function described herein can be implemented as a session management policy control entity.

[0029] Figure 1 An example communication environment 100 in which example embodiments of the present disclosure can be implemented is shown. Figure 1 In a specific example, the communication environment 100 includes multiple communication network devices, including device 110 and network entity 120. For example... Figure 1 As shown, device 110 and network entity 120 can communicate with each other.

[0030] In the following description, for illustrative purposes, some example embodiments are described, in which a user equipment is an example of device 110 and an Internet Protocol Multimedia Subsystem (IMS) application server is an example of network entity 120. However, in some example embodiments, the operations described in connection with the user equipment can be implemented at any other suitable device, and the operations described in connection with the IMS application server can be implemented at any other suitable network entity or network function.

[0031] It should be understood that Figure 1 The number of devices and their connections shown are for illustrative purposes only and do not imply any limitation. Communication environment 100 may include any suitable number of devices configured to implement the exemplary embodiments of this disclosure. In some exemplary embodiments, communication environment 100 may also include another device (not shown), a network device such as a gNB (not shown), another network entity (not shown), a home subscriber server (not shown), a third party such as an external application server (not shown), etc. The scope of this disclosure is not limited in this respect.

[0032] Communication in communication environment 100 can be implemented according to any suitable communication protocol(s), including but not limited to cellular communication protocols, wireless local area network communication protocols (such as IEEE 802.11), and / or any other currently known or future-developed protocols. Furthermore, communication can utilize any suitable wireless communication technology, including but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple Input Multiple Output (MIMO), Orthogonal Frequency Division Multiple Access (OFDM), Discrete Fourier Transform Extended OFDM (DFT-s-OFDM), and / or any other currently known or future-developed technologies.

[0033] In the existing design, based on a request from the network side (e.g., from the DC application server (AS)), an IMS-based application or bootstrap data channel (DC) can be added to an existing IMS session, or it can be created as an independent DC between two UEs or between a UE and the network.

[0034] The call flow of network-initiated P2P ADC added to an existing IMS session has been studied. Figure 2 The signaling diagram for a sample IMS session with a network-initiated P2P ADC is shown. Figure 2 As shown, a P2P DC was added between UE B207 and UE A 209 in the example IMS session.

[0035] At point 215, an IMS session has been established between UE A 209 and UE B 207, and a bootstrapping DC has also been established. At point 220, the DC application server (AS) 201 can determine to add a P2P data channel to an existing IMS session based on local policies or event notifications of the relevant IMS sessions subscribed to by DC AS 201. For example, the Open Mobile Alliance (OMA) Application Programming Interface (API) can be used for non-DC session notifications at point 220.

[0036] At position 221, DC AS 201 sends an Nnef_ImsSessionManagement_Update request to NEF 202, requesting the addition of (multiple) P2P application data channels to an existing IMS session. For example, DC AS 201 may include the session ID of the existing session, the operation type (e.g., add), the media type (e.g., P2P ADC), the UE B 207 and UE A 209 targeted as the P2P ADC, and the application (App) binding information from the Nnef_ImsSessionManagement_Update request. Furthermore, DC AS 201 may include the notification target address and related ID in the Nnef_ImsSessionManagement_Update request to notify the progress of the session update.

[0037] At 222, if needed, NEF 202 can query the Home Subscriber Server (HSS) for IMS ASs serving a specific UE. For example, NEF 202 can use the Nhss_ImsUECM_AsInfoGet service operation to retrieve IMS AS instances serving target user UE B 207, and discover IMS ASs from the NRF if necessary.

[0038] At 223, NEF 202 can send a Nimsas_ImsSessionManagement_Update request to IMS AS-2 203, requesting the addition of (multiple) P2P application data channels in a specific session. The received request may include the session ID of the existing session, the operation type as added, the media type as the P2P ADC, the UE B 207 and UE A209 as the target of the P2P ADC, and application binding information.

[0039] Then, IMS AS-2 203 verifies the user's data subscription and checks the UE's IMS DC capability, determining whether a data channel request should be notified to Data Channel Signalling Function (DCSF)-2 204. If the serving UE does not have an IMS data channel subscription or IMS DC capability, the request can be rejected for an appropriate reason, and subsequent steps can be skipped. If the same IMS data channel has already been established, the request can be rejected for an appropriate reason, and subsequent steps can be skipped. If IMS AS-2 203 allows the request to proceed, it can return a successful Nimsas_SessionManagement_Update response to NEF 202 at 224. For example, a successful Nimsas_SessionManagement_Update response may include the associated session ID. At 225, NEF 202 returns a successful Nnef_SessionManagement_Update response to DC AS 201.

[0040] At 226, IMS AS-2 203 may send a Nimsas_SessionEventControl_Notify request to DCSF-2 204 with an event set to 3rdPartySessionUpdate. This notification includes the media action set received at 223. At 227, after receiving the session event notification, DCSF-2 204 may determine whether a DC has been provided and determine the DC control policy. For example, DCSF-2 204 may determine a policy on how to handle application data channel establishment requests based on relevant parameters in the notification (e.g., associated DC application binding information) and / or DCSF-2 204 service-specific policies.

[0041] At 228, DCSF-2 204 determines that the proposed additional application data channel media will target UE B 207 and UEA 209 as endpoints and needs to be anchored between them in the MF. DCSF-2 204 can create originating and terminating DC media information. At 229, DCSF-2 204 instructs IMS AS-2 203 to establish (multiple) data channels by sending a Nimsas_MediaControl request.

[0042] At 230, depending on the instructions from DCSF-2 204, IMS AS-2 203 can interact with MF-2 205 to allocate data channel media resources to UE B 207 and UE A 209. For example, IMS AS-2 203 can request MF-2 205 to create DC media resources, and MF-2 205 can allocate DC media resources to UE B 207 and UE A 209. At 231, IMS AS-2 203 can respond to a Nimsas_MediaControl request from DCSF-2 204, and at 232, DCSF-2 204 can respond to a Nimsas_SessionEventControl_Notify request from IMS AS-2 203.

[0043] At 233, IMS AS-2 203 can generate multiple re-invitation requests, where the Session Description Protocol (SDP) proposal includes media information for the data channel, application binding information, existing session ID, and other existing media descriptions. IMSAS-2 203 can send multiple re-invitation requests to the target UE B 207 via IMS Core-2 206. It should be noted that the DC media is set to hold until step 239 is performed.

[0044] At 234, DC media negotiation can be performed, for example, by using messages such as 18x / PRACK / 200 OK / PRACK / Update. After DC media negotiation is completed, at 235, UE B 207 returns a 200 OK response with an SDP response for the applied DC via IMS core-2 206.

[0045] At 236, IMS AS-2 203 can generate (multiple) re-invitation requests, where the SDP proposal includes media information for the data channel, application binding information, existing session ID, and other existing media descriptions. IMS AS-2 203 can send (multiple) re-invitation requests to target UE A 209 via IMS core-2 206 and originating network (NW) 208. It should be noted that the DC media is set to hold until step 240 is performed.

[0046] At 237, DC media negotiation can be performed, for example, by using messages such as 18x, PRACK, 200 OK (PRACK), update, etc. After DC media negotiation is complete, UE A 209 can return a 200 OK response with an SDP response for the applied DC at 238. It should be noted that steps 233 to 235 and steps 236 to 238 described above can be processed in parallel.

[0047] At 239, IMS AS-2 203 can request MF-2 205 to update the media resource information on the UE B 207 and UE A 209 sides based on the SDP responses for the application DC received from UE B 207 and UE A 209. At 240, IMS AS-2 203 can send ACKs to UE-B and UE A 209.

[0048] At 241, if DC AS 201 includes a subscription to the DC session event of the Nnef_ImsSessionManagement_Update request at 221, then IMS AS-2 203 can use the Nimsas_SessionManagement_Notify request to notify NEF 202 of the progress of the session update.

[0049] At point 242, NEF 202 can use the Nnef_SessionManagement_Notify request to notify DC AS 201 of the progress of the session update. At point 243, DC AS 201 can return an Nnef_SessionManagement_Notify response to NEF 202. At point 244, NEF 202 can return a Nimsas_SessionManagement_Notify response to IMS AS-2 203.

[0050] It should be understood that although the above process is described in the reference P2P use case, the same principles apply to P2A2P and A2P use cases.

[0051] In existing designs, when an IMS DC establishment request is triggered by the network (e.g., based on a request from a DC AS), the following issues arise: How can the calling and / or called party know that the establishment request was initiated by an application via the network, rather than by the corresponding UE? If users cannot distinguish between UE-initiated and application-initiated IMS DCs, they may be misled into authorizing the ADC establishment request without knowing the true initiator, and therefore this feature may not be acceptable to users. Furthermore, operators may be unable to deploy this feature due to potential regulatory issues related to user awareness.

[0052] The exemplary embodiments of this disclosure provide a solution for indicating the source of an IMS session establishment request. In one solution, the device receives a request to establish an IMS session (e.g., an IMS Data Channel (DC) session) from a network entity. This request indicates that the initiator of the request is from the network side, a third party, or a user equipment. Based on the initiator, the device determines acceptance information regarding the establishment of the IMS session. This acceptance information indicates whether the device accepts the establishment of the IMS session.

[0053] In this way, the device can distinguish between the initiator of the IMS session to be established and the network side, the UE side, or a third party. Therefore, the IMS session can be established in an efficient manner.

[0054] Further details of exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0055] Figure 3 Signaling diagram 300 for indicating the source of an establishment request according to some example embodiments of this disclosure is shown. Reference will be made to this diagram for discussion purposes. Figure 1 Signaling diagram 300 is discussed, for example, using device 110 and network entity 120. In some example embodiments, device 110 may include a terminal device, such as a UE. Network entity 120 may include an IMS application server, etc.

[0056] In signaling diagram 300, network entity 120 determines (310) whether the establishment of the IP Multimedia Subsystem (IMS) session with the device is initiated from the network side, a third party, or a user device.

[0057] In addition, network entity 120 transmits (320) a request to device 110 for the establishment of an IMS session. This request indicates whether the initiator of the request is from the network side, a third party, or a user device. Optionally, when the initiator of the request is a third party, the request may also include information about the third party to allow the user to identify the third party. By way of example and not limitation, an IMS session may include an IMS data channel session, etc. Additionally or alternatively, a third party may include an external application server, etc.

[0058] In some example embodiments, the request may include an indication of the initiator. For example, a first value of the indication may be used to indicate that the initiator is from the network side or a third party, and a second value of the indication may be used to indicate that the initiator is a user equipment. The first value is different from the second value.

[0059] In some alternative example embodiments, the presence of an indication of the initiator in the request can be used to indicate that the initiator is from the network side or a third party. The absence of an indication in the request can be used to indicate that the initiator is a user equipment. More specifically, if an indication is present in the request, it means that the IMS session was initiated from the network side or a third party; otherwise, if an indication is missing in the request, it means that the IMS session was initiated by the UE.

[0060] In some example embodiments, the initiator's indication may be included in the request header. As an example, the request may include a Session Initiation Protocol (SIP) request message, and a new conditional SIP header label may be used to indicate the origin of the initiator. This will be described in detail below. Alternatively, the initiator's indication may be included in the Session Description Protocol (SDP) section of the request body. As an example, a new line 'a' in the SDP proposal may be used to indicate the origin of the initiator. Alternatively, the initiator's indication may be included in the Display Name field from the (From) header, for example, the "Display Name" is set to "UE-xxx representing DS AS-yyy". In this example, "xxx" may be the UE's public UE ID, and "yyy" may be the application ID / name. This informational approach allows users to know the request initiator and then comply with privacy regulations and ethical rules such as transparency. Thus, the initiator's indication can be transmitted in a manner compatible with existing (multiple) communication protocols. It should be understood that the possible implementations of the initiator's indication described herein are merely illustrative and should not be construed as limiting this disclosure in any way.

[0061] In some example embodiments, the request may also include the identifier of another device (e.g., another UE, etc.) with which the IMS session will be established. With the aid of this identifier, the IMS session can be established efficiently.

[0062] Device 110 receives (330) a request to establish an IMS session from network entity 120 and determines (340) acceptance information regarding the establishment of the IMS session based on the initiator. The acceptance information indicates whether device 110 accepts the establishment of the IMS session. In some example embodiments, the acceptance information may be determined based on device 110's policies (such as security policies). For example, if the initiator of the request is included in a whitelist of the security policy, device 110 may accept the establishment of the IMS session. If the initiator of the request is included in a blacklist of the security policy, device 110 may reject the establishment of the IMS session. It should be understood that the above description is for illustrative purposes only. The scope of this disclosure is not limited in this respect. In some alternative or additional example embodiments, device 110 may prompt the user to manually accept or reject the request.

[0063] In some example embodiments, if device 110 accepts the establishment of an IMS session, then device 110 can perform the establishment of the IMS session. If device 110 rejects the establishment of an IMS session, then device 110 can transmit information about rejecting the establishment of the IMS session to network entity 120. Accordingly, network entity 120 can receive information about rejecting the establishment of the IMS session from device 110.

[0064] In light of the above, the proposed solution advantageously enables the differentiation between UE-initiated IMS DCs and application-initiated IMS DCs. Therefore, users can leverage the knowledge of the true initiator to authorize ADC establishment requests, thereby mitigating regulatory issues related to user perception.

[0065] In some example embodiments, device 110 may transmit data relating to the establishment of an IMS session with respect to device 110 to a Home Subscriber Server (HSS). The data from device 110 may be transmitted to the HSS via a network portal. In one example embodiment, the data may be used to indicate whether device 110 accepts the establishment of an IMS session initiated from the network side or a third party. Additionally or alternatively, the data may indicate whether device 110 accepts the establishment of an IMS session initiated from a user equipment. In yet another example embodiment, the data may indicate information about which third party or user equipment device device device device device device device the device 110 accepts the establishment of an IMS session from.

[0066] Furthermore, network entity 120 can obtain data from the HSS related to the establishment of an IMS session with device 110. If the request to establish an IMS session is verified based on the data of device 110, network entity 120 can transmit the request to device 110. Therefore, the data stored in the HSS can be used to control the establishment request, thus allowing for more efficient control of the establishment request.

[0067] In some example embodiments, in response to receiving another request associated with the establishment of an IMS session from another network entity 120, which may be, for example, a Network Open Function (NEF) or a Data Channel Application Server, network entity 120 can determine that the establishment of the IMS session was initiated from the network side or a third party. As an example, and not a limitation, this other request could be a Nimsas_ImsSessionManagement_Update request, etc. In response to receiving a message associated with the establishment of an IMS session from another device (e.g., another UE), network entity 120 can determine that the establishment of the IMS session was initiated from a user equipment. As not a limitation, this message could be a SIP invitation message, a SIP re-invitation message, etc. Thus, the user can leverage knowledge of the true initiator to authorize the ADC establishment request.

[0068] In light of the above, this paper proposes several solutions, at least aimed at indicating the source of the IMS DC establishment request. In some example embodiments, a new Conditional Session Initiation Protocol (SIP) header label (represented as network initiator, etc.) is proposed to indicate that the DC establishment request is triggered by an application / DC AS, a third party, or a UE. In some example embodiments, when the source is a UE, the label can be set to false (e.g., network initiator: false) or no label may be given. If the source is the network side, such as a DC AS, the label can be set to true (e.g., network initiator: true). Alternatively, existing SIP headers can be used to convey information about whether the request is network-initiated. As another alternative, the DC media information in the SDP can include such an indication, for example, as part of the SDP attribute (a) line. The a line in the SDP has the form a=<attribute>:<value>, in which case, for example, a=network initiator: yes / false, is provided in the SDP proposal within the SIP invitation request. For example, if the SIP header label is Network Initiator: True, or if the SDP a line is a=Network Initiator: Yes, then the ID or address of the application / DC AS can be included in the SIP header or the SDP a line.

[0069] In some example embodiments, the IMS AS can determine whether the request is initiated by the network, as this requires a network function (NF) (e.g., a DC AS) to invoke a specific IMS AS service operation. Once determined, the IMS AS can instruct the network-initiated IMS DC establishment in a SIP or SDP and send it to the UE to indicate that the IMS DC establishment request was initiated by the network side. Furthermore, the IMS AS can provide the UE with the identity of the party establishing the IMS DC (e.g., the IMS Public User (IMPU) identity), and the UE or user can use this identity to decide whether to accept the IMS DC.

[0070] In some example embodiments, upon receiving the aforementioned network initiator instruction, the UE can identify the source of the IMS DC establishment request. Based on the UE's security policy, the UE can decide to accept or reject the establishment request. Alternatively, the UE can prompt the user to manually accept or reject the request. The decision to accept or reject the request can be based on the identity of the other party provided in the request. For example, if the identity is part of the user's phonebook, the user can decide to accept the request; otherwise, the user can decide to reject the request.

[0071] In some additional example embodiments, the IMS AS can also indicate the source of the IMS DC establishment request to the DCSF, for example, by indicating the new event initiator "DC AS" in the Nimsas_SessionEventControl_Notify message. This information can be used by the DCSF as part of the IMS DC policy control.

[0072] In some alternative or additional example embodiments, user consent established for network-initiated IMS DCs can be stored in each subscriber's HSS. Alternatively, a user can only allow IMS DCs with a specific number of IMPUs, which are stored in the HSS.

[0073] In view of the above, this disclosure provides a solution for indicating the source of an IMS DC establishment request. More specifically, in a first solution according to some example embodiments of this disclosure, a new SIP header can be used to indicate the source of the IMS DC establishment request. In a second solution according to some example embodiments of this disclosure, a new line 'a' in the SDP can be used to indicate the source of the IMS DC establishment request. In a third solution according to some example embodiments of this disclosure, data stored in the HSS can be used to indicate the source of the IMS DC establishment request.

[0074] In response to the first solution, a new conditional SIP header label is proposed to indicate the source of DC setup and update requests. For ease of discussion, this conditional SIP header label can be represented as the network initiator. It should be understood that this conditional SIP header label can also be represented by any other suitable string. The scope of this disclosure is not limited in this respect.

[0075] As an example, and not a limitation, the format for a tag network initiator can be defined as follows: Online initiator: <True / False> ● True: When a DC establishment / update request is initiated from the network side; ● False: When the DC establishment / update request is initiated from the UE side.

[0076] An example implementation of this first solution can be as follows:

[0077] It should be understood that the above-described exemplary implementation of the first solution is shown for illustrative purposes only. The scope of this disclosure is not limited in this respect.

[0078] In some alternative example embodiments, when the DC establishment / update request is initiated from the UE side, the tag network initiator may not be present in the SIP header.

[0079] For the second solution, a new line 'a' from the SDP proposal can be used to convey an indication of whether the network has initiated an IMSDC establishment request. For ease of discussion, this line 'a' can be represented as the network initiator. It should be understood that this line 'a' can also be represented by any other suitable string. The scope of this disclosure is not limited in this respect.

[0080] As an example, and not a limitation, the format for the network initiator in line a can be defined as follows: a = Network initiator: Yes / No ● Yes, this applies when a DC establishment / update request is initiated from the network side; ● False when DC establishment / update request is initiated from the UE side.

[0081] An example implementation of this second solution can be as follows:

[0082] It should be understood that the above example implementation of the second solution is shown for illustrative purposes only. The scope of this disclosure is not limited in this respect.

[0083] In some alternative example embodiments, when the DC establishment / update request is initiated from the UE side, the new a-line network initiator may not exist in the SIP header.

[0084] For the third solution, the user can provide their user consent data regarding accepting or rejecting IMS DC establishment requests in the HSS. The IMS DC establishment request from the network to the user / UE can be user-controlled by data stored in the HSS. For example, the user can authorize the network to initiate an IMS DC, where user consent is stored in the HSS (network-initiated IMS DCs may optionally allow or disallow a list of permitted DC applications). Alternatively, the user can allow the establishment of an IMS DC with another user only if a list of users permitted to establish IMS DCs is stored in each subscriber's HSS.

[0085] As an example and not a limitation, users may allow IMS DCs to be established for the following numbers (IMPU): +X41234567, +X96539992, +X98766332, +X38762900, etc. It should be understood that the specific numbers or values ​​described herein are intended as examples and not to limit the scope of this disclosure.

[0086] The IMS AS can identify the source of the request as the network because an AF (e.g., a DC AS) is required to invoke a specific IMSAS service operation. However, if the source is a UE, the UE invokes the request as defined in 3GPP Rel-18 and Rel-19. For example, the IMS AS receives a Nimsas_SessionManagement_Create or Nimsas_SessionManagement_Update request from the NEF, which originates from a DC AS. It should be noted that a trusted DC AS can send the Nnef_ImsSessionManagement_Create or Nnef_ImsSessionManagement_Update request directly to the IMS AS without going through the NEF.

[0087] In some example embodiments of the first solution described above, after the DC media resources (and MDC2 media resources) are allocated and media resources are negotiated via SIP or SDP messages, the IMS AS can add a new header tag to the SIP header, namely, Network Initiator: True. In some example embodiments of the second solution described above, after the DC media resources (and MDC2 media resources) are allocated and media resources are negotiated via SIP or SDP messages, the IMS AS can add a new line 'a' to the SDP, namely, a = Network Initiator: Yes.

[0088] Additionally, the identity of the other party (e.g., the calling UE) can also be included in the SIP message, which will later assist operations in the called UE. Alternatively or additionally, if IMSDCs initiated to a particular called UE's network are allowed or not allowed, the IMS AS can verify user consent stored in the HSS before generating the SIP or SDP message.

[0089] After receiving a SIP or SDP message from the IMS AS, the UE can use the network initiator indication in the SIP or SDP message to identify the source of the IMS DC establishment request.

[0090] Based on the UE's security policy, the UE can decide to accept or reject a connection request. Alternatively, the UE can prompt the user to manually accept or reject the request. The decision to accept or reject a request can also be based on the identity of the other party provided in the request. For example, if the identity is part of the user's phonebook, the user can decide to accept the request. If the identity is not part of the user's phonebook, the user can decide to reject the request.

[0091] It should be noted that after receiving a Nimsas_SessionManagement_Create or Nimsas_SessionManagement_Update request, IMS AS can also provide an indicator to DCSF in a Nimsas_SessionEventControlNotify message. This information can be used by DCSF as part of DC policy control.

[0092] The following will refer to Figure 4 and 5 Please describe the above solution in detail. Figure 4 Signaling diagram 400 illustrates an example IMS session of P2P DC between two UEs according to some example embodiments of this disclosure. (Regarding...) Figure 4 In the example embodiments discussed, UE A 409 or UE B 407 may be Figure 1 An example implementation of device 110 in the example, and IMS AS-2 403 can be Figure 1 The example implementation of network entity 120 is shown below. It should be noted that the apparatus and network entity can also be implemented in any other suitable manner. The scope of this disclosure is not limited in this respect.

[0093] At point 415, the IMS session between UE A 409 and UE B 407 may have been established, and the bootstrap DC may have also been established.

[0094] At step 420, DC AS 401 can request that the P2P ADC between UE B 407 and UE A 409 be added to an existing IMS session. As an example, step 420 can be done using a similar... Figure 2 The operations shown in steps 220 to 223 are implemented.

[0095] At position 421, IMS AS-2 403 can receive a Nimsas_ImsSessionManagement_Update request originating from DC AS 401 from NEF 402, instead of a SIP invitation or SIP re-invitation message from the UE. Therefore, IMS AS-2 403 determines that the P2P ADC establishment request was initiated from the network side rather than from the UE side.

[0096] At 422, IMS AS-2 403 can verify the request based on user consent data stored in HSS-2. For example, IMS AS-2 403 can verify user subscription data and check the UE's IMS DC capability. Furthermore, IMS AS-2 403 can determine whether the data channel request should be notified to DCSF-2 404. If the serving UE does not have an IMS data channel subscription or does not have IMS DC capability, the request can be rejected for an appropriate reason, and subsequent steps can be skipped. Alternatively, if the same IMS data channel has already been established, the request can be rejected for an appropriate reason, and subsequent steps can be skipped. If IMS AS-2 403 allows the request to proceed, IMS AS-2 403 can return a successful Nimsas_SessionManagement_Update response to NEF 402 at 424.

[0097] At 425, NEF 402 can return a successful Nnef_SessionManagement_Update response to DC AS 401. At 426, IMS AS-2 403 can send a Nimsas_SessionEventControl_Notify request with an event set to 3rdPartySessionUpdate to DCSF-2 404. This notification can include a set of media operations received from NEF 402, and can indicate that the request was initiated from the network side by setting the event initiator to "DC AS 401". At 428, session control and media control can be performed at IMS AS-2 403. In some example embodiments, it is possible to utilize... Figure 2 Steps 227 to 232 shown are similar to the operations performed to perform session control and media control.

[0098] At 430, IMS AS-2 403 transmits multiple re-invitation requests to UE B 407, where the SDP proposal includes media information for the data channel, application binding information, existing session IDs, and other existing media descriptions. In one example embodiment, IMS AS-2 403 may set the SIP header label Network Initiator value to true and add the SIP header label Network Initiator to the multiple re-invitation request headers. In another example embodiment, IMS AS-2 403 may add, a=Network Initiator: Yes, as a new line a in the SDP, and IMS AS-2 403 sends multiple re-invitation requests to UE B 407. It should be noted that the DC media is set to hold until step 440 is executed.

[0099] At 432, UE B 407 can identify that DC AS 401 from the network side is the source of the establishment request. UE B 407 can decide to accept or reject the establishment request, for example, based on the SIP header label "Network Initiator" or line a in the SDP: a=Network Initiator. Alternatively, UE B 407 can prompt the user to manually accept or reject the request. At 433, if the establishment request is rejected, the following steps may not be performed, and UE B 407 can return a message to IMS AS-2 403 to reject the establishment request, for example, SIP 607 rejection.

[0100] At 434, DC media negotiation can be performed, for example, by using messages such as 18x, PRACK, 200 OK (PRACK), update, etc. After DC media negotiation is complete, UE B 407 can return a 200 OK response with an SDP response for the applied DC at 435.

[0101] At 436, IMS AS-2 403 can transmit multiple re-invitation requests to UE A 409, where the SDP proposal includes media information for the data channel, application binding information, existing session ID, and other existing media descriptions. In one example embodiment, IMS AS-2 403 can set the SIP header label Network Initiator value to true and add the SIP header label Network Initiator to the header of the multiple re-invitation requests. Alternatively, IMS AS-2 403 can add a=Network Initiator: Yes to the SDP as a new line a. IMS AS-2 403 then sends the multiple re-invitation requests to the target UE A 409. It should be noted that the DC medium can be set to hold until step 440 is performed.

[0102] At 437, UE A 409 can identify DC AS 401 from the network side as the source of the establishment request. UE A 409 can decide to accept or reject the establishment request. Alternatively, UE A 409 can prompt the user to manually accept or reject the request. If the establishment request is rejected, subsequent steps may not be performed, and at 438, UE A 409 can return a message to IMS AS-2403 to reject the establishment request, for example, SIP 607 rejection.

[0103] At point 440, DC media negotiation and media resource information updates can be performed. In some example embodiments, DC media negotiation and media resource information updates can utilize, for example, […]. Figure 2 Steps 237 to 240 shown are performed in a similar manner.

[0104] At position 442, session management updates can be performed by IMS AS-2 403. In some example embodiments, session management updates can utilize, for example, Figure 2 Steps 241 to 244 shown are performed in a similar manner.

[0105] Reference Figure 5 Describe the third solution described above in detail. Figure 5 Signaling diagram 500 is shown, according to some example embodiments of this disclosure, for verifying user consent regarding a P2P ADC establishment request initiated by a DC AS. Regarding... Figure 5 In the example embodiments discussed, UE A 509 and / or UE B 507 may be Figure 1 An example implementation of device 110 in the example, and IMS AS-2 503 can be Figure 1 The example implementation of network entity 120 is shown below. It should be noted that the apparatus and network entity can also be implemented in any other suitable manner. The scope of this disclosure is not limited in this respect.

[0106] At 511, UE B 507 may provide its user consent regarding the IMS DC establishment request at HSS-2 510. For example, user consent may be regarding accepting or rejecting DC AS 501 as the initiator. Additionally or alternatively, UE A 509 may also provide its user consent in the HSS of its own network. At 513, HSS-2 510 may utilize this provision in response. It should be noted that although the above provisioning process has been described first, this provisioning process can be performed at any time prior to step 522.

[0107] At step 515, the IMS session between UE A 509 and UE B 507 may have already been established, and the bootstrap DC may have also been established. At step 520, DC AS 501 may request that the P2P ADC between UE B 507 and UE A 509 be added to the existing IMS session. As an example, step 520 can be done using a similar approach. Figure 2 The operations shown in steps 220 to 223 are implemented.

[0108] At point 522, IMS AS-2 503 can receive a Nimsas_ImsSessionManagement_Update request from DC AS 501 via NEF 502, instead of a SIP invitation or SIP re-invitation message from the UE. Therefore, IMS AS-2 503 can determine that the P2P ADC establishment request was initiated from the network side rather than the UE side.

[0109] At 523, IMS AS-2 503 can verify the request based on user consent data stored in HSS-2 510. If the verification is successful, i.e., UE B 507 can accept the IMS DC establishment request initiated by DC AS 501, then proceed with the subsequent steps.

[0110] IMS AS-2 503 can verify the user's data subscription and check the UE's IMS DC capability, determining whether a data channel request should be notified to DCSF-2. If the serving UE does not have an IMS data channel subscription or IMS DC capability, the request can be rejected for an appropriate reason, and subsequent steps can be skipped. Alternatively, if the same IMS data channel has already been established, the request will be rejected for an appropriate reason, and subsequent steps will be skipped. If IMS AS-2 503 allows the request to proceed, it can return a successful Nimsas_SessionManagement_Update response to NEF 502 at 524.

[0111] At 524, if the verification of user consent at 523 fails, i.e., UE B 507 may not accept the IMS DC establishment request initiated by DC AS501, then IMS AS-2 503 can return a failed Nimsas_SessionManagement_Update response to NEF 502.

[0112] At point 525, NEF 502 can return a successful Nnef_SessionManagement_Update response to DC AS 501. If IMS AS-2 503 returns a failed Nimsas_SessionManagement_Update response to NEF 502, then NEF 502 can return a failed Nnef_SessionManagement_Update response to DC AS 501 and can skip the remaining steps.

[0113] At 530, one or more procedures can be performed, such as session control and media control, SIP configuration to UE B 507 and UEA 509, and optionally, session management notification. In some example embodiments, these procedures can be similar to Figure 2 The operations shown in steps 226 to 244 are performed. Alternatively, these processes can be performed using methods similar to... Figure 4 The operations shown in steps 426 to 442 are performed. The scope of this disclosure is not limited in this respect.

[0114] It should be understood that although the proposed solution is described above with reference to the specific use case of adding a P2PDC between UE B 507 and UE A 509 in an existing IMS session, the proposed solution can also be used for other use cases, such as adding P2A2P and A2P DCs in an existing IMS session, or creating standalone P2A2P and A2P DCs, etc. The scope of this disclosure is not limited in this respect.

[0115] Given the above, the proposed solution advantageously enables the differentiation between UE-initiated IMS DCs and application-initiated IMS DCs. Therefore, users can leverage the knowledge of the true initiator to authorize ADC establishment requests, thus mitigating regulatory issues related to user perception.

[0116] Figure 6 A flowchart of an example method 600 implemented at a device according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1 The angle description method of device 110 in the middle is 600.

[0117] At box 610, device 110 receives a request from a network entity for the establishment of an IP Multimedia Subsystem (IMS) session. This request indicates whether the request originated from the network side, a third party, or a user device.

[0118] In block 620, device 110 determines acceptance information regarding the establishment of an IMS session based on the initiator, the acceptance information indicating whether the device accepts the establishment of the IMS session.

[0119] In view of the above, device 110 can distinguish between the initiator of the IMS session to be established and the network side, UE side, or third party. Therefore, the IMS session can be established in an effective manner.

[0120] In some example embodiments, the request may include an indication from the initiator, and a first value of the indication may be used to indicate that the initiator is from the network side or a third party, and a second value of the indication may be used to indicate that the initiator is a user device, the first value being different from the second value.

[0121] Alternatively, in some example embodiments, the presence of an indication of the initiator in the request can be used to indicate that the initiator is from the network side or a third party, and the absence of an indication in the request can be used to indicate that the initiator is a user equipment.

[0122] In any of the methods discussed above, information about the source of the IMS session establishment request can be transmitted efficiently via signaling.

[0123] In some example embodiments, the indication may be included in the request header or in the Session Description Protocol (SDP) section of the request body. Therefore, the indication can be carried by the request in various ways.

[0124] In some example embodiments, the request may also include the identifier of another device with which the IMS session will be established. This identifier allows the user to know who initiated the request and thus comply with privacy regulations and ethical rules such as transparency. Simultaneously, the initiator's instructions can be transmitted in a manner compatible with (multiple) existing communication protocols.

[0125] In some example implementations, the request may include a Session Initiation Protocol (SIP) request message.

[0126] In some example embodiments, acceptance information may be determined based on a device policy. The policy may be, for example, a security policy or any other suitable policy. Based on the security policy, device 110 may decide to accept or reject the IMS session establishment request. Alternatively, device 110 may prompt the user to accept or reject the request. According to this policy, the decision to accept or reject the request may be based on the identity of the other party provided in the request. For example, if the other party's identity is part of the user's phonebook, the user may decide to accept the request; otherwise, they may reject it. In this way, acceptance information can be determined in a flexible manner.

[0127] In some example embodiments, device 110 may also transmit data related to the establishment of an IMS session to the home subscriber server. In some example embodiments, the data is used to indicate at least one of the following: whether the device accepts that the establishment of the IMS session was initiated from the network side or from a third party, whether the device accepts that the establishment of the IMS session was initiated from a user equipment, or information about which third party or user equipment the device accepts the establishment of the IMS session from. Therefore, the data of device 110 related to the establishment of the IMS session can be pre-stored or recorded at the home subscriber server for further inspection.

[0128] In some example embodiments, if it is determined that the device accepts the establishment of an IMS session, the device 110 may perform the establishment of an IMS session; and if it is determined that the device rejects the establishment of an IMS session, the device 110 may transmit information about the rejection of the establishment of an IMS session to the network entity.

[0129] In some example embodiments, an IMS session may include an IMS data channel session.

[0130] In some example embodiments, the device may include user equipment, the network entity may include an IMS application server, and the third party may include an external application server.

[0131] Figure 7 A flowchart of an example method 700 implemented at a network entity according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1 Method 700 is described from the perspective of network entity 120.

[0132] At box 710, network entity 120 determines that the establishment of the IP Multimedia Subsystem (IMS) session with the device was initiated from the network side, a third party, or the user equipment.

[0133] In box 720, network entity 120 transmits a request to the device for the establishment of an IMS session, the request indicating whether the initiator of the request is from the network side, a third party, or a user device.

[0134] In some example embodiments, the request may include an indication from the initiator. A first value of the indication may be used to indicate that the initiator is from the network side or a third party, and a second value of the indication may be used to indicate that the initiator is a user equipment, the first value being different from the second value.

[0135] In some example embodiments, the presence of an indication of the initiator in the request can be used to indicate that the initiator is from the network side or a third party, and the absence of an indication in the request can be used to indicate that the initiator is a user equipment.

[0136] In some example embodiments, the indication may be included in the request header or in the Session Description Protocol (SDP) section of the request body.

[0137] In some example embodiments, the request may also include the identifier of another device with which an IMS session will be established.

[0138] In some example implementations, the request may include a Session Initiation Protocol (SIP) request message or may be a SIP request message.

[0139] In some example embodiments, network entity 120 may also receive information from the device regarding the rejection of IMS session establishment.

[0140] In some example embodiments, network entity 120 may determine that the establishment of the IMS session was initiated from the network side or a third party in response to receiving another request associated with the establishment of the IMS session from another network entity, including a Network Open Function (NEF) or a Data Channel Application Server; and determine that the establishment of the IMS session was initiated from the user equipment in response to receiving a message associated with the establishment of the IMS session from another device.

[0141] In some example embodiments, network entity 120 may also obtain data related to the establishment of an IMS session with the device from the home subscriber server; and if it is determined that the request for the establishment of an IMS session is verified based on the data of the device, the request is transmitted to the device.

[0142] In some example embodiments, the data may be used to indicate at least one of the following: whether the device accepts the establishment of the IMS session from the network side or from a third party, whether the device accepts the establishment of the IMS session from the user equipment, or information about which third party or user equipment the device accepts the establishment of the IMS session from.

[0143] In some example embodiments, an IMS session may include an IMS data channel session.

[0144] In some example embodiments, the device may include user equipment, the network entity may include an IMS application server, and the third party may include an external application server.

[0145] In some example embodiments, the apparatus capable of performing any method 600 (e.g., Figure 1 The device 110 may include a component for performing the corresponding operation of method 600. This component may be implemented in any suitable form. For example, the component may be implemented in a circuit system or a software module. The device may be implemented as or included in... Figure 1 In device 110.

[0146] In some example embodiments, the apparatus includes: components for receiving from a network entity a request for the establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that the initiator of the request is from the network side, a third party, or a user equipment; and components for determining acceptance information regarding the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.

[0147] In some example embodiments, the request includes an indication of the initiator, wherein a first value of the indication is used to indicate that the initiator is from the network side or a third party, and a second value of the indication is used to indicate that the initiator is a user equipment, and the first value is different from the second value.

[0148] In some example embodiments, the presence of an indication of the initiator in the request is used to indicate that the initiator is from the network side or a third party, and the absence of an indication in the request is used to indicate that the initiator is a user equipment.

[0149] In some example embodiments, the instruction is included in the request header or in the Session Description Protocol (SDP) section of the request body.

[0150] In some example embodiments, the request also includes the identifier of another device with which the IMS session will be established.

[0151] In some example implementations, the request includes a Session Initiation Protocol (SIP) request message.

[0152] In some example embodiments, the acceptance of information is determined based on the device's strategy.

[0153] In some example embodiments, the apparatus further includes a component for transmitting data relating to the establishment of an IMS session to the home subscriber server.

[0154] In some example embodiments, the data is used to indicate at least one of the following: whether the device accepts the establishment of the IMS session from the network side or from a third party, whether the device accepts the establishment of the IMS session from the user equipment, or information about which third party or user equipment the device accepts the establishment of the IMS session from.

[0155] In some example embodiments, the apparatus further includes: a component for performing the establishment of an IMS session if it is determined that the apparatus accepts the establishment of an IMS session; and a component for transmitting information about the rejection of the establishment of an IMS session to a network entity if it is determined that the apparatus rejects the establishment of an IMS session.

[0156] In some example embodiments, an IMS session includes an IMS data channel session.

[0157] In some example embodiments, the device includes user equipment, the network entity includes an IMS application server, and the third party includes an external application server.

[0158] In some example embodiments, network entities capable of performing any method 700 (e.g., Figure 1 The network entity 120 in the network may include a component for performing the corresponding operation of method 700. This component can be implemented in any suitable form. For example, the component can be implemented in a circuit system or a software module. The network entity can be implemented as or included in... Figure 1 Among network entities 120.

[0159] In some example embodiments, the network entity includes: a component for determining whether the establishment of an IP Multimedia Subsystem (IMS) session with the device is initiated from the network side, a third party, or a user equipment; and a component for transmitting a request to the device for the establishment of the IMS session, the request indicating that the initiator of the request is from the network side, a third party, or a user equipment.

[0160] In some example embodiments, the request includes an indication of the initiator, wherein a first value of the indication is used to indicate that the initiator is from the network side or a third party, and a second value of the indication is used to indicate that the initiator is a user equipment, and the first value is different from the second value.

[0161] In some example embodiments, the presence of an indication of the initiator in the request is used to indicate that the initiator is from the network side or a third party, and the absence of an indication in the request is used to indicate that the initiator is a user equipment.

[0162] In some example embodiments, the instruction is included in the request header or in the Session Description Protocol (SDP) section of the request body.

[0163] In some example embodiments, the request also includes the identifier of another device with which the IMS session will be established.

[0164] In some example implementations, the request includes a Session Initiation Protocol (SIP) request message.

[0165] In some example embodiments, the network entity further includes a component for receiving information from the device regarding the rejection of the establishment of an IMS session.

[0166] In some example embodiments, the network entity further includes: a component for determining, in response to receiving another request associated with the establishment of the IMS session from another network entity including a Network Open Function (NEF) or a Data Channel Application Server, that the establishment of the IMS session was initiated from the network side or a third party; and a component for determining, in response to receiving a message associated with the establishment of the IMS session from another device, that the establishment of the IMS session was initiated from a user equipment.

[0167] In some example embodiments, the network entity further includes: a component for obtaining data from the home subscriber server relating to the establishment of an IMS session with the device; and a component for transmitting a request to the device if it is determined that the request for the establishment of the IMS session has been verified based on the device's data.

[0168] In some example embodiments, the data is used to indicate at least one of the following: whether the device accepts the establishment of the IMS session initiated from the network side or from a third party, whether the device accepts the establishment of the IMS session initiated from the user equipment, or information about which third party or user equipment the device accepts the establishment of the IMS session from.

[0169] In some example embodiments, an IMS session includes an IMS data channel session.

[0170] In some example embodiments, the device includes user equipment, the network entity includes an IMS application server, and the third party includes an external application server.

[0171] Figure 8 This is a simplified block diagram of a device 800 suitable for implementing exemplary embodiments of the present disclosure. The device 800 can be provided to implement a communication device, such as... Figure 1 The device 110 or network entity 120 shown. As shown, device 800 includes one or more processors 810, one or more memories 820 coupled to processor 810, and one or more communication modules 840 coupled to processor 810.

[0172] Communication module 840 is used for bidirectional communication. Communication module 840 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interface can represent any interface necessary for communication with other network elements. In some example embodiments, communication module 840 may include at least one antenna.

[0173] As a non-limiting example, processor 810 can be any type suitable for a local technology network and can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 800 can have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock that synchronizes with the main processor.

[0174] Memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), optical disc, laser disc, and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 822 and other volatile memories that will not persist for extended periods of power-off duration.

[0175] Computer program 830 includes computer-executable instructions that are executed by an associated processor 810. The instructions of program 830 may include instructions for performing operations / actions of some example embodiments of this disclosure. Program 830 may be stored in memory (e.g., ROM 824). Processor 810 can perform any suitable actions and processes by loading program 830 into RAM 822.

[0176] Example embodiments of this disclosure can be implemented by program 830, enabling device 800 to perform as described in the reference. Figures 3 to 7Any process discussed in this disclosure. Exemplary embodiments of this disclosure may also be implemented by hardware or a combination of software and hardware.

[0177] In some example embodiments, program 830 may be tangibly contained in a computer-readable medium, which may be included in device 800 (such as in memory 820) or other storage devices accessible by device 800. Device 800 may load program 830 from the computer-readable medium into RAM 822 for execution. In some example embodiments, the computer-readable medium may include any type of non-transitory storage medium, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. As used herein, the term "non-transitory" refers to a limitation on the medium itself (i.e., tangible, not tactile), rather than a limitation on the persistence of data storage (e.g., RAM versus ROM).

[0178] Figure 9 An example of a computer-readable medium 900 is shown, which may be in the form of a CD, DVD, or other optical storage disc. The computer-readable medium 900 has a program 830 stored thereon.

[0179] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, and others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware, or controllers or other computing devices, or some combination thereof, as non-limiting examples.

[0180] Some exemplary embodiments of this disclosure also provide at least one computer program product tangibly stored on a computer-readable medium, such as a non-transitory computer-readable medium. The computer program product includes computer-executable instructions, such as those instructions included in a program module, a device on a target physical or virtual processor, and executed to perform any of the methods described above. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform a particular task or implement a particular abstract data type. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The machine-executable instructions for a program module can execute within a local or distributed device. In a distributed device, the program module can reside on both local and remote storage media.

[0181] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0182] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0183] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media will include electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0184] Furthermore, although operations are described in a specific order, this should not be construed as requiring that such operations be performed in the specific order shown or sequentially, or requiring that all shown operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure, but rather as a description of features that may be specific to particular embodiments. Unless explicitly stated otherwise, certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated otherwise, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0185] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. An apparatus comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Receive a request from a network entity to establish an IP Multimedia Subsystem (IMS) session, the request indicating whether the initiator of the request is from the network side, a third party, or a user device; as well as The acceptance information for the establishment of the IMS session is determined based on the initiator, and the acceptance information is used to indicate whether the device accepts the establishment of the IMS session.

2. The apparatus of claim 1, wherein the request includes an instruction to the initiator, and The first value of the indication is used to indicate that the initiator is from the network side or a third party, and the second value of the indication is used to indicate that the initiator is a user equipment, wherein the first value is different from the second value.

3. The apparatus of claim 1, wherein the presence of an indication of the initiator in the request is used to indicate that the initiator is from the network side or a third party, and the absence of the indication in the request is used to indicate that the initiator is a user equipment.

4. The apparatus of claim 2 or 3, wherein the indication is included in the header of the request or in the Session Description Protocol (SDP) portion of the body of the request.

5. The apparatus according to any one of claims 1 to 4, wherein the request further includes the identifier of another apparatus, with which the IMS session will be established.

6. The apparatus according to any one of claims 1 to 5, wherein the request includes a Session Initiation Protocol (SIP) request message.

7. The apparatus according to any one of claims 1 to 6, wherein the acceptance information is determined based on the strategy of the apparatus.

8. The apparatus according to any one of claims 1 to 7, wherein the apparatus is configured to: Data relating to the establishment of the IMS session to the device is transmitted to the home subscriber server.

9. The apparatus of claim 8, wherein the data is used to indicate at least one of the following: Whether the device accepts that the establishment of the IMS session was initiated from the network side or from a third party. Whether the device accepts that the establishment of the IMS session was initiated by the user equipment, or The device receives information about which third party or user equipment the IMS session was established from, or for which data channel the device receives information about which network-initiated IMS session was established.

10. The apparatus according to any one of claims 1 to 9, wherein the apparatus is configured to: If it is determined that the device accepts the establishment of the IMS session, the establishment of the IMS session is performed; and If it is determined that the device rejects the establishment of the IMS session, information regarding the rejection of the establishment of the IMS session is transmitted to the network entity.

11. The apparatus according to any one of claims 1 to 10, wherein the IMS session includes an IMS data channel session.

12. The apparatus according to any one of claims 1 to 11, wherein the apparatus includes a user equipment, the network entity includes an IMS application server, and the third party includes an external application server.

13. A network entity, comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: It is determined whether the establishment of the IP Multimedia Subsystem (IMS) session with the device was initiated from the network side, a third party, or the user equipment; as well as The device transmits a request for the establishment of the IMS session, the request indicating that the initiator of the request is from the network side, a third party, or a user equipment.

14. The network entity of claim 13, wherein the request includes an instruction to the initiator, and The first value of the indication is used to indicate that the initiator is from the network side or a third party, and the second value of the indication is used to indicate that the initiator is a user equipment, wherein the first value is different from the second value.

15. The network entity of claim 13, wherein the presence of the indication of the initiator in the request is used to indicate that the initiator is from the network side or a third party, and the absence of the indication in the request is used to indicate that the initiator is a user equipment.

16. The network entity of claim 14 or 15, wherein the indication is included in the header of the request or in the Session Description Protocol (SDP) portion of the body of the request.

17. The network entity according to any one of claims 13 to 16, wherein the request further includes the identifier of another device, with which the IMS session will be established.

18. The network entity according to any one of claims 13 to 17, wherein the request includes a Session Initiation Protocol (SIP) request message.

19. The network entity according to any one of claims 13 to 18, wherein the network entity is such that: Receive information from the device regarding the rejection of the establishment of the IMS session.

20. The network entity according to any one of claims 13 to 19, wherein the network entity is such that: In response to receiving another request associated with the establishment of the IMS session from another network entity, including Network Open Function (NEF) or Data Channel Application Server, it is determined that the establishment of the IMS session was initiated from the network side or a third party; and In response to receiving a message associated with the establishment of the IMS session from another device, it is determined that the establishment of the IMS session was initiated from the user equipment.

21. The network entity according to any one of claims 13 to 20, wherein the network entity is such that: Obtain data from the home subscriber server relating to the establishment of the IMS session to the device; and If it is determined that the request to establish the IMS session is verified based on the data of the device, the request is transmitted to the device.

22. The network entity of claim 21, wherein the data is used to indicate at least one of the following: Whether the device accepts that the establishment of the IMS session was initiated from the network side or from a third party. Whether the device accepts that the establishment of the IMS session was initiated by the user equipment, or The device receives information about which third party or user equipment the IMS session was established from, or for which data channel the device receives information about which network-initiated IMS session was established.

23. The network entity according to any one of claims 13 to 22, wherein the IMS session includes an IMS data channel session.

24. The network entity according to any one of claims 13 to 23, wherein the apparatus includes user equipment, the network entity includes an IMS application server, and the third party includes an external application server.

25. A method comprising: Receive a request from a network entity to establish an IP Multimedia Subsystem (IMS) session, the request indicating whether the initiator of the request is from the network side, a third party, or a user device; as well as Based on the initiator, acceptance information regarding the establishment of the IMS session is determined, and the acceptance information is used to indicate whether the device accepts the establishment of the IMS session.

26. A method comprising: It is determined whether the establishment of the IP Multimedia Subsystem (IMS) session with the device was initiated from the network side, a third party, or the user equipment; as well as The device transmits a request for the establishment of the IMS session, the request indicating that the initiator of the request is from the network side, a third party, or a user equipment.

27. An apparatus comprising: A component for receiving a request from a network entity for establishing an IP Multimedia Subsystem (IMS) session, the request indicating whether the initiator of the request is from the network side, a third party, or a user equipment. as well as A component for determining acceptance information regarding the establishment of the IMS session based on the initiator, the acceptance information indicating whether the device accepts the establishment of the IMS session.

28. A network entity, comprising: The component used to determine whether the establishment of an IP Multimedia Subsystem (IMS) session with the device is initiated from the network side, a third party, or the user equipment; as well as A component for transmitting a request to the device for establishing the IMS session, the request indicating that the initiator of the request is from the network side, a third party, or a user equipment.

29. A computer-readable medium comprising instructions stored thereon, the instructions being configured to cause a device to perform at least the method of claim 25 or the method of claim 26.

Images