Indicating origin of IMS session establishment request
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-02-10
- Publication Date
- 2026-08-13
Smart Images
Figure CN2025076726_13082026_PF_FP_ABST
Abstract
Description
INDICATING ORIGIN OF IMS SESSION ESTABLISHMENT REQUESTFIELD
[0001] Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for indicating an origin of an IP Multimedia Subsystem (IMS) session establishment request.BACKGROUND
[0002] A communication network may serve as a facility that enables communications between two or more communication devices or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. A communication device may be provided with a service by an application server.
[0003] The communication network may operate in accordance with standards such as those provided by Third Generation Partnership Project (3GPP) or European Telecommunications Standards Institute (ETSI) . Examples of standards provided by 3GPP are the so-called 3GPP standards for cellular technology generations, such as 3GPP standards for 4G technology, 5G technology, 6G technology, and so on.SUMMARY
[0004] In a first aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; and determine acceptance information about 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 the present disclosure, there is provided a network entity. The network entity comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network entity at least to: determine whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; and transmit, to the apparatus, a request for the establishment of the IMS session, the request indicating that an initiator of the request is from the network side, a third party or a user equipment.
[0006] In a third aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; and determining acceptance information about the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.
[0007] In a fourth aspect of the present disclosure, there is provided a method. The method comprises: determining whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; and transmitting, to the apparatus, a request for the establishment of the IMS session, the request indicating that an initiator of the request is from the network side, a third party or a user equipment.
[0008] In a fifth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; and means for determining acceptance information about 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 the present disclosure, there is provided a network entity. The network entity comprises means for determining whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; and means for transmitting, to the apparatus, a request for the establishment of the IMS session, the request indicating that an initiator of the request is from the network side, a third party or a user equipment.
[0010] In a seventh aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the third aspect.
[0011] In an eighth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the fourth aspect.
[0012] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS
[0013] Some example embodiments will now be described with reference to the accompanying drawings, where:
[0014] FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented;
[0015] FIG. 2 illustrates a signaling chart for an example IMS session with network initiated person to person (P2P) application data channel (ADC) ;
[0016] FIG. 3 illustrates a signaling chart for indicating origin of an establishment request according to some example embodiments of the present disclosure;
[0017] FIG. 4 illustrates a signaling chart for an example IMS session with a P2P DC between two UEs in accordance with some example embodiments of the present disclosure;
[0018] FIG. 5 illustrates a signaling chart for validating user consent about data channel (DC) application server (AS) initiated P2P ADC establishment request in accordance with some example embodiments of the present disclosure;
[0019] FIG. 6 illustrates a flowchart of a method implemented at an apparatus in accordance with some example embodiments of the present disclosure;
[0020] FIG. 7 illustrates a flowchart of a method implemented at a network entity in accordance with some example embodiments of the present disclosure;
[0021] FIG. 8 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and
[0022] FIG. 9 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
[0023] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION
[0024] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.
[0025] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.
[0026] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
[0027] It shall be understood that although the terms “first, ” “second, ” …, etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.
[0028] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.
[0029] As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.
[0030] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.
[0031] As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable) : (i) a combination of analog and / or digital hardware circuit (s) with software / firmware and (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
[0032] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example, and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
[0033] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , 5.5G, the sixth generation (6G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.
[0034] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.
[0035] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
[0036] As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and / or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.
[0037] A core network function as described herein may be implemented as a core network entity that includes a combination of hardware processing circuit and software and / or firmware comprising machine-readable instructions, or software comprising machine-readable instructions that are executable by at least one processor of hardware processing circuit of an apparatus. A hardware processing circuit includes at least one processor and at least one memory storing machine-readable instructions that are executable by the at least one processor of the hardware processing circuit. A processor includes any or some combination of an accelerator, a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, a central processing unit, a graphic processing unit, a tensor processing unit. Memory includes any or some combination of volatile or non-volatile memory (e.g., a flash memory, cache, a random-access memory (RAM) , and / or a read-only memory (ROM) ) . The memory stores the machine-readable instructions of the software and / or firmware for execution by the at least one processor of the hardware processing circuit. The machine-readable instructions are executable by the at least one processor of the hardware processing circuit cause the hardware processing circuit to perform the actions or operations of the methods described herein. For example, the session management function described herein may be implemented as a session management entity and the session management policy control function described herein may be implemented as a session management policy control entity, respectively.
[0038] FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented. In the specific example of FIG. 1, communication environment 100 comprises a plurality of communication network devices, including an apparatus 110 and a network entity 120. As shown in FIG. 1, the apparatus 110 and the network entity 120 may communicate with each other.
[0039] In the following, for the purpose of illustration, some example embodiments are described with a user equipment as an example of the apparatus 110, and an internet protocol multimedia subsystem (IMS) application server as an example of the network entity 120. However, in some example embodiments, operations described in connection with the user equipment may be implemented at any other suitable device, and operations described in connection with the IMS application server may be implemented at any other suitable network entity or network function.
[0040] It should be understood that the number of devices and their connections shown in FIG. 1 are only for the purpose of illustration without suggesting any limitation. The communication environment 100 may include any suitable number of devices configured to implementing example embodiments of the present disclosure. In some example embodiments, the communication environment 100 may further comprises a further apparatus (not shown) , a network device such as a gNB (not shown) , a further network entity (not shown) , a home subscriber server (not shown) , a third party such as an external application server (not shown) and / or the like. The scope of the present disclosure is not limited in this respect.
[0041] Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising 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 (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.
[0042] In an existing design, an IMS based application or bootstrap data channel (DC) may be added to an existing IMS session or may be created as a standalone DC between two UEs or between a UE and a network, according to a request from the network side, e.g., from a DC application server (AS) .
[0043] A call flow of network initiated P2P ADC added in an existing IMS session has been studied. FIG. 2 illustrates a signaling chart for an example IMS session with network initiated P2P ADC. As shown in FIG. 2, a P2P DC between a UE B 207 and a UE A 209 is added in the example IMS session.
[0044] At 215, an IMS session between the UE A 209 and the UE B 207 has been established, and a bootstrap DC has been also established. At 220, a DC application server (AS) 201 may determine to add a P2P data channel to an existing IMS session based on a local policy or an event notification of the related IMS Session which the DC AS 201 subscribes to. For example, an open mobile alliance (OMA) application programming interface (API) may be used for a non-DC session notification at 220.
[0045] At 221, the DC AS 201 sends a Nnef_ImsSessionManagement_Update request to a NEF 202 requiring adding a P2P application data channel (s) in the existing IMS session. For example, the DC AS 201 may include session ID of the existing session, the operation type as Adding, the media type as P2P ADC, the UE B 207 and the UE A 209 as the targets of the P2P ADC, and the application (App) binding information in the Nnef_ImsSessionManagement_Update request. In addition, the DC AS 201 may include a Notification Target Address and Correlation ID to the Nnef_ImsSessionManagement_Update request to be notified for the progress of the session update.
[0046] At 222, the NEF 202 may query a home subscriber server (HSS) for the IMS AS serving a specific UE if needed. For example, the NEF 202 may use the Nhss_ImsUECM_AsInfoGet service operation to retrieve the IMS AS instance serving the targeted user UE B 207 and discovers the IMS AS from NRF if needed.
[0047] At 223, the NEF 202 may send a Nimsas_ImsSessionManagement_Update request to an IMS AS-2 203 requiring to add a P2P application data channel (s) in the specific session. The received session ID of the existing session, the operation type as Adding, the media type as P2P ADC, the UE B 207 and UE A 209 as the targets of the P2P ADC, and the App binding information may be included in the received request.
[0048] Then, the IMS AS-2 203 validates the user subscription data and checks the IMS DC capability of UE and determines whether the data channel request should be notified to a data channel signaling function (DCSF) -2 204. If the serving UE does not have subscription of IMS data channel or does not have the IMS DC capability, then the request may be rejected with appropriate cause and the following steps may be skipped. If the same IMS data channel is already established, then the request may be rejected with an appropriate cause and the following steps may be skipped. If the IMS AS-2 203 allows the request to proceed, the IMS AS-2 203 may return a successful Nimsas_SessionManagement_Update response to the NEF 202 at 224. For example, the successful Nimsas_SessionManagement_Update response may comprise an associated session ID. At 225, the NEF 202 returns a successful Nnef_SessionManagement_Update response to the DC AS 201.
[0049] At 226, the IMS AS-2 203 may send a Nimsas_SessionEventControl_Notify request to the DCSF-2 204 with an event set to 3rdPartySessionUpdate. The notification includes the Media operation set as received at 223. At 227, after receiving the session event notification, the DCSF-2 204 may determine whether DC is provided and determines the DC control policy. For example, the DCSF-2 204 may determine the policy about how to process the application data channel establishment request based on the related parameters (e.g., associated DC application binding information) in the notification and / or a DCSF-2 204 service specific policy.
[0050] At 228, the DCSF-2 204 may determine that the added Application Data Channel media of the offer takes UE B 207 and UE A 209 as target endpoint and requires to anchor in the MF in between. The DCSF-2 204 may create originating and terminating side DC media information. At 229, the DCSF-2 204 instructs the IMS AS-2 203 to set up the data channel (s) by sending a Nimsas_MediaControl request.
[0051] At 230, depending on the instruction from the DCSF-2 204, the IMS AS-2 203 may interact with a MF-2 205 to allocate data channel media resource (s) towards the UE B 207 and the UE A 209. For example, the IMS AS-2 203 may request the MF-2 205 to create a DC media resource, and the MF-2 205 may allocate the DC media resource towards the UE B 207 and the UE A 209. At 231, the IMS AS-2 203 may respond to Nimsas_MediaControl request from the DCSF-2 204, and at 232, the DCSF-2 204 may respond to the Nimsas_SessionEventControl_Notify from the IMS AS-2 203.
[0052] At 233, the IMS AS-2 203 may generate a re-INVITE request (s) in which the session description protocol (SDP) offer contains the media information of the data channel, application binding information, the existing session ID with the other existing media descriptions. The IMS AS-2 203 may send the re-INVITE request (s) to the target UE B 207 via an IMS CORE-2 206. It should be noted that the DC media is set to on hold until the following step 239 is performed.
[0053] At 234, a DC media negotiation may be performed, e.g., by using messages such as 18x / PRACK / 200 OK / PRACK / UPDATE, and / or the like. After the DC media negotiation is completed, at 235, the UE B 207 returns a 200 OK respond with SDP answer for the application DC via the IMS CORE-2 206.
[0054] At 236, the IMS AS-2 203 may generate a re-INVITE request (s) in which the SDP offer contains the media information of the data channel, application binding information, the existing session ID with the other existing media descriptions. The IMS AS-2 203 may send the re-INVITE request (s) to the target UE A 209 via the IMS CORE-2 206 and an originating network (NW) 208. It should be noted that the DC media is set to on hold until the following step 240 is performed.
[0055] At 237, a DC media negotiation may be performed, e.g., by using messages such as 18x, PRACK, 200 OK (PRACK) , UPDATE, and / or the like. After the DC media negotiation is completed, the UE A 209 may return a 200 OK respond with SDP answer for the application DC at 238. It should be noted that the above-described Steps 233-235 and Steps 236-238 may be processed in parallel.
[0056] At 239, the IMS AS-2 203 may request the MF-2 205 to update UE B 207 side and UE A 209 side media resource information based on the received SDP answer for the application DC from the UE B 207 and the UE A 209. At 240, the IMS AS-2 203 may send an ACK to the UE-B and the UE A 209.
[0057] At 241, if the DC AS 201 included a subscription to the DC session events to the Nnef_ImsSessionManagement_Update request at 221, the IMS AS-2 203 may notify the NEF 202 for the progress of the session update with the Nimsas_SessionManagement_Notify request.
[0058] At 242, the NEF 202 may notify the DC AS 201 for the progress of the session update with the Nnef_SessionManagement_Notify request. At 243, the DC AS 201 may return a Nnef_SessionManagement_Notify response to the NEF 202. At 244, the NEF 202 may return a Nimsas_SessionManagement_Notify response to the IMS AS-2 203.
[0059] It should be understood that although the above process is described with reference to a P2P use case, the same principle is applicable for P2A2P and A2P use cases.
[0060] In the existing design, when an IMS DC establishment request is triggered by the network (e.g., based on a request from a DC AS) , there is a problem about how a calling party and / or called party may be aware that the establishment request is initiated by an application through the network and not by the opposite UE. If a user cannot distinguish between a UE-initiated IMS DC and an application-initiated IMS DC, the user may be misled to authorize the ADC establishment request without knowing the real initiator and in consequence the feature may not be accepted by the users. In addition, since a regulatory issue may be caused on user awareness, the feature may not be deployed by the operators.
[0061] Example embodiments of the present disclosure propose solutions for indicating an origin of an IMS session establishment request. In a solution, an apparatus receives, from a network entity, a request for an establishment of an IMS session (e.g., an IMS data channel (DC) session) . The request indicates that an initiator of the request is from network side, a third party or a user equipment. Based on the initiator, the apparatus determines acceptance information about the establishment of the IMS session. The acceptance information indicates whether the apparatus accepts the establishment of the IMS session.
[0062] In this way, the apparatus can distinguish the initiator of the IMS session to be established is from the network side, the UE side or the third party. Thus, the IMS session may be established in an efficient way.
[0063] More details of the example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.
[0064] FIG. 3 illustrates a signaling chart 300 for indicating origin of an establishment request according to some example embodiments of the present disclosure. For the purposes of discussion, the signaling chart 300 will be discussed with reference to FIG. 1, for example, by using the apparatus 110 and the network entity 120. In some example embodiments, the apparatus 110 may comprise a terminal device, such as a UE or the like. The network entity 120 may comprise an IMS application server, or the like.
[0065] In the signaling chart 300, the network entity 120 determines (310) whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment.
[0066] Moreover, the network entity 120 transmits (320) , to the apparatus 110, a request for the establishment of the IMS session. The request indicates that an initiator of the request is from the network side, a third party or a user equipment. When the initiator of the request is from a third party, optionally the request may also include information of the third party to allow the user identifying the third party. By way of example rather than limitation, the IMS session may comprise an IMS data channel session or the like. Additionally or alternatively, the third party may comprise an external application server or the like.
[0067] In some example embodiments, the request may comprise an indication of the initiator. For example, a first value of the indication may indicate that the initiator is from the network side or the third party, and a second value of the indication may indicate that the initiator is a user equipment. The first value is different from the second value.
[0068] In some alternative example embodiments, presence of an indication of the initiator in the request may indicate that the initiator is from the network side or the third party. An absence of the indication in the request may indicate that the initiator is the user equipment. More specifically, if there is the indication in the request, it means that the IMS session is initialed from the network side or the third party; otherwise, if the indication is absent from the request, it means the IMS session is initialed by a UE.
[0069] In some example embodiments, the indication of the initiator may be comprised in a header of the request. By way of example, the request may comprise a session initiation protocol (SIP) request message, and a new conditional SIP header tag may be employed to indicate the origin of the initiator. This will be described in detail below. Alternatively, the indication of the initiator may be comprised in a Session Description Protocol (SDP) section in a body of the request. By way of example, a new a-line in the SDP offer may be employed to indicate the origin of the initiator. Alternatively, the indication of the initiator may be comprised in the display-name field of the From header, e.g. the “display-name” is set to “UE-xxx on behalf of the DS AS-yyy” . In this example, “xxx” may be UE public UE ID and “yyy” may be application ID / name. This manner of information may allow the user to be aware of the request initiator, then comply with privacy regulation and ethics rule such as transparency. Thereby, the indication of the initiator can be conveyed in a manner compatible to the existing communication protocol (s) . It should be understood that the possible implementations of the indication of the initiator described here are merely illustrative and therefore should not be construed as limiting the present disclosure in any way.
[0070] In some example embodiments, the request may further comprise an identification of a further apparatus (e.g., a further UE or the like) with which the IMS session is to be established. In aid of such an identification, the IMS session can be established efficiently.
[0071] The apparatus 110 receives (330) the request for the establishment of the IMS session from the network entity 120, and determines (340) acceptance information about the establishment of the IMS session based on the initiator. The acceptance information indicates whether the apparatus 110 accepts the establishment of the IMS session. In some example embodiments, the acceptance information may be determined based on a policy (such as a security policy or the like) of the apparatus 110. For example, if the initiator of the request is comprised in a whitelist of the security policy, the apparatus 110 may accept the establishment of the IMS session. If the initiator of the request is comprised in a blacklist of the security policy, the apparatus 110 may reject the establishment of the IMS session. It should be understood that the above illustrations are described merely for purpose of description. The scope of the present disclosure is not limited in this respect. In some alternative or additional example embodiments, the apparatus 110 may alert the user to accept or reject the request manually.
[0072] In some example embodiments, if the apparatus 110 accepts the establishment of the IMS session, the apparatus 110 may perform the establishment of the IMS session. If the apparatus 110 rejects the establishment of the IMS session, the apparatus 110 may transmit to the network entity 120, information on rejection of the establishment of the IMS session. Correspondingly, the network entity 120 may receive, from the apparatus 110, information on rejection of the establishment of the IMS session.
[0073] In view of the above, the proposed solution can advantageously make it possible to distinguish between UE-initiated IMS DC and application-initiated IMS DC. Thereby, the user can authorize the ADC establishment request with the knowledge of the real initiator, and thus the regulatory issue on user awareness can be mitigated.
[0074] In some example embodiments, the apparatus 110 may transmit to a home subscriber server (HSS) , data of the apparatus 110 related to the establishment of an IMS session towards the apparatus 110. The data of the apparatus 110 may be transmitted to the HSS via a web portal. In one example embodiment, the data may indicate whether the apparatus 110 accepts that the establishment of the IMS session is initiated from network side or from a third party. Additionally or alternatively, the data may indicate whether the apparatus 110 accepts that the establishment of the IMS session is initiated from a user equipment. In a still further example embodiments, the data may indicate information from which third party or user equipment the apparatus 110 accepts the establishment of the IMS session.
[0075] Moreover, the network entity 120 may obtain, from the HSS, the data of the apparatus 110 related to the establishment of an IMS session towards the apparatus 110. If the request for the establishment of the IMS session is validated based on the data of the apparatus 110, the network entity 120 may transmit the request to the apparatus 110. Thereby, the data stored in the HSS may be utilized to control the establishment request, and thus the establishment request can be controlled more efficiently.
[0076] In some example embodiments, in response to receiving, from a further network entity 120 which may be for example a network exposure function (NEF) or a data channel application server, a further request associated with the establishment of the IMS session, the network entity 120 may determine that the establishment of the IMS session is initiated from network side or a third party. By way of example rather than limitation, this further request may be a Nimsas_ImsSessionManagement_Update request and / or the like. In response to receiving, from a further apparatus (e.g., another UE) , a message associated with the establishment of the IMS session, the network entity 120 may determine that the establishment of the IMS session is initiated from a user equipment. By way of rather than limitation, this message may be an SIP INVITE message, an SIP re-INVITE message, or the like. Thereby, the user can authorize the ADC establishment request with the knowledge of the real initiator.
[0077] In view of the above, several solutions have been proposed herein at least aiming at indicating origin of an IMS DC establishment request. In some example embodiments, a new conditional session initiation protocol (SIP) header tag (denoted as networkinitiator or the like) is proposed to indicate that the DC establishment request is trigged by an application / DC AS or a third party or a UE. In some example embodiments, a tag may be set to false (e.g., networkinitiator: FALSE) or the tag may not be given, in the case where the origin is the UE. The tag may be set to be true (e.g., networkinitiator: TRUE) , if the origin is the network side, e.g., the DC AS. Alternatively, an existing SIP header may be used to convey the information whether the request is network-initiated. As a further alternative, the DC media information in SDP may contain such an indication, e.g., as part of an SDP attribute (a) -line. An a-line in SDP has the form a=<attribute>: <value>, in this case, e.g. a=networkinitiator: yes / false is provided in the SDP offer inside a SIP INVITE request. For example, if the SIP header tag is networkinitiator: TRUE or if the SDP a-line is a=networkinitiator: yes, the application / DC AS’s ID or address may be included in the SIP header or the SDP a-line.
[0078] In some example embodiments, the IMS AS may determine if the request is initiated by the network as this requires a network function (NF) (e.g. the DC AS) to invoke a specific IMS AS service operation. Once determined, the IMS AS may indicate the network-initiated IMS DC establishment in SIP or SDP and send it to the UE, to indicate that the IMS DC establishment request is initiated by the network side. In addition, the IMS AS may provide the identity (e.g., IMS public user (IMPU) identity) of the party with which the IMS DC is established to the UE, and the UE or user may use this identity to decide whether to accept the IMS DC or not.
[0079] In some example embodiments, upon receiving the above-mentioned networkinitiator indication, the UE may identify the origin of the IMS DC establishment request. Based on the security policy of the UE, the UE may decide to accept or reject the establishment request. Alternatively, the UE may alert the user to accept or reject the request manually. 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 identity is part of the user’s phone book, the user may decide to accept the request; otherwise, the user may decide to reject the request.
[0080] In some additional example embodiments, the IMS AS may also indicate the origin of the IMS DC establishment request towards a DCSF, e.g., by indicating a new event initiator “DC AS” in the Nimsas_SessionEventControl_Notify message. The information may be used by the DCSF as part of IMS DC policy control.
[0081] In some alternative or additional example embodiments, the user consent for the network-initiated IMS DC establishment may be stored in the HSS per subscriber. Alternatively, the user may allow the IMS DC only to a certain number of IMPUs which are stored in the HSS.
[0082] In view of the foregoing, the present disclosure provides solutions for indicating the origin of an IMS DC establishment request. More specifically, in a first solution according to some example embodiments of the present disclosure, a new SIP header may be employed to indicate the origin of the IMS DC establishment request. In a second solution according to some example embodiments of the present disclosure, a new a-line in SDP may be employed to indicate the origin of the IMS DC establishment request. In a third solution according to some example embodiments of the present disclosure, data stored in the HSS may be employed to indicate the origin of the IMS DC establishment request.
[0083] For the first solution, a new conditional SIP header tag is proposed to indicate the origin of the DC establishment request and updating request. For ease of discussion, this conditional SIP header tag may be denoted as networkinitiator. It should be understood that this conditional SIP header tag may also be denoted with any other suitable string. The scope of the present disclosure is not limited in this respect.
[0084] By way of example rather than limitation, the format of the tag networkinitiator may be defined as follows: networkinitiator: <TRUE / FALSE> ● TRUE: when the DC establishment / updating request is initiated from network side; ● FALSE: when the DC establishment / updating request is initiated from UE side.
[0085] An example implementation of this first solution may be as follows:
[0086] It should be understood that the above example implementation of the first solution is shown merely for purpose of illustration. The scope of the present disclosure is not limited in this respect.
[0087] In some alternative example embodiments, this tag networkinitiator may also not be present in the SIP header, when the DC establishment / updating request is initiated from UE side.
[0088] For the second solution, a new a-line in the SDP offer may be employed to convey indication whether network has initiated the IMS DC establishment request. For ease of discussion, this a-line may be denoted as networkinitiator. It should be understood that this a-line may also be denoted with any other suitable string. The scope of the present disclosure is not limited in this respect.
[0089] By way of example rather than limitation, the format of the a-line networkinitiator may be defined as follows: a=networkinitiator: yes / false ●yes when the DC establishment / updating request is initiated from network side; ●false when the DC establishment / updating request is initiated from UE side.
[0090] An example implementation of this second solution may be as follows:
[0091] It should be understood that the above example implementation of the second solution is shown merely for purpose of illustration. The scope of the present disclosure is not limited in this respect.
[0092] In some alternative example embodiments, this new a-line networkinitiator may also not be present in the SIP header, when the DC establishment / updating request is initiated from UE side.
[0093] For the third solution, a user may provide his / her user consent data about the acceptance or rejection of an IMS DC establishment request in the HSS. IMS DC establishment request from the network towards a user / UE may be user controlled by data stored in the HSS. For example, network may be authorized by the user to initiate an IMS DC, where the user consent is stored in the HSS (network-initiated IMS DC allowed optionally with a list of allowed DC applications or not allowed) . Alternatively, the user may allow establishment of an IMS DC to another user only where the list of user identities for which IMS DC establishment is allowed is stored in the HSS per subscriber.
[0094] By way of example rather than limitation, a user may allow IMS DC to be established towards following numbers (IMPUs) : +X41234567, +X96539992, +X98766332, +X38762900, and / or the like. It should be understood that the specific numbers or values recited herein are intended to be examples rather than limiting the scope of the present disclosure.
[0095] The IMS AS may identify that the origin of the request is the network, since an AF (e.g. DC AS) is required to invoke the specific IMS AS service operation. However, UE invokes the request if the origin is the UE, as defined in 3GPP Rel-18 and Rel-19. For example, the IMS AS receives the Nimsas_SessionManagement_Create or Nimsas_SessionManagement_Update request from NEF, which is originated from DC AS by the Nnef_ImsSessionManagement_Create or Nnef_ImsSessionManagement_Update request. It should be noted that a trusted DC AS may send the Nnef_ImsSessionManagement_Create or Nnef_ImsSessionManagement_Update request directly to the IMS AS without going through the NEF.
[0096] In some example embodiments for the above-mentioned first solution, after the DC media resource (and the MDC2 media resource) is allocated, along with the media resource negotiation via SIP or SDP messages, the IMS AS may add the new header tag, i.e., networkinitiator: TRUE, in the SIP header. In some example embodiments for the above-mentioned second solution, after the DC media resource (and the MDC2 media resource) is allocated, along with the media resource negotiation via SIP or SDP messages, the IMS AS may add the new a-line, i.e., a=networkinitiator: yes, in the SDP.
[0097] In addition, the identity of another party (e.g., calling party UE) may also be included in the SIP message, that will assist the operation in the called party UE later. Alternative or in addition, the IMS AS may validate the user consent stored in the HSS before generating the SIP or SDP message, if network-initiated IMS DC towards certain called party UEs is allowed or not.
[0098] Upon receiving the SIP or SDP messages from the IMS AS, the UE may identify the origin of the IMS DC establishment request using the networkinitiator indication in the SIP or SDP messages.
[0099] Based on the security policy of the UE, the UE may decide to accept or reject the establishment request. Alternatively, the UE may alert the user to accept or reject the request manually. The decision to accept or reject the request may be further based on the identity of the other party provided in the request. For example, if the identity is part of the user’s phone book, the user may decide to accept the request. If the identity is not part of the user’s phone book, the user may decide to reject the request.
[0100] It should be noted that, upon receiving the Nimsas_SessionManagement_Create or Nimsas_SessionManagement_Update request, the IMS AS may also provide the indicator to the DCSF in the Nimsas_SessionEventControl Notify message. The information may be used by the DCSF as a part of DC policy control.
[0101] The above-mentioned solutions will be described in detail below with reference to FIGS. 4 and 5. FIG. 4 illustrates a signaling chart 400 for an example IMS session with a P2P DC between two UEs in accordance with some example embodiments of the present disclosure. In example embodiments discussed with respect to FIG. 4, a UE A 409 or a UE B 407 may be an example implementation of the apparatus 110 in FIG. 1, and the IMS AS-2 403 may be an example implementation of the network entity 120 in FIG. 1. It should be noted that the apparatus and the network entity may also be implemented in any other suitable manner. The scope of the present disclosure is not limited in this respect.
[0102] At 415, an IMS session between the UE A 409 and the UE B 407 may have been established, and a bootstrap DC may have been also established.
[0103] At 420, the DC AS 401 may request to add a P2P ADC between the UE B 407 and the UE A 409 to an existing IMS session. By way of the example, step 420 may be implemented with operations similar to steps 220-223 as shown in FIG. 2.
[0104] At 421, the IMS AS-2 403 may receive the Nimsas_ImsSessionManagement_Update request from NEF 402, which originates from the DC AS 401, instead of an SIP INVITE or SIP re-INVITE message from UE. Therefore, the IMS AS-2 403 determines that the P2P ADC establishment request is initiated from the network side, not from the UE side.
[0105] At 422, the IMS AS-2 403 may validate the request based on the user consent data stored in the HSS-2. For example, the IMS AS-2 403 may validate the user subscription data and checks the IMS DC capability of UE. Moreover, the IMS AS-2 403 may determine whether the data channel request should be notified to DCSF-2 404. If the serving UE does not have subscription of IMS data channel or does not have the IMS DC capability, then the request may be rejected with an appropriate cause and subsequent steps may be skipped. Additionally or alternatively, if the same IMS data channel has been already established, then the request may be rejected with an appropriate cause and the following steps are skipped. If the IMS AS-2 403 allows the request to proceed, the IMS AS-2 403 may return a successful Nimsas_SessionManagement_Update response to the NEF 402 at 424.
[0106] At 425, the NEF 402 may return a successful Nnef_SessionManagement_Update response to the DC AS 401. At 426, the IMS AS-2 403 may send a Nimsas_SessionEventControl_Notify request to the DCSF-2 404 with an event set to 3rdPartySessionUpdate. The notification may include the media operation set as received from the NEF 402, and may indicate that the request is initiated from the network side by setting the event initiator as “DC AS 401” . At 428, session control and media control may be performed at IMS AS-2 403. In some example embodiments, the session control and the media control may be performed with operations similar to the steps 227-232 shown in FIG. 2.
[0107] At 430, the IMS AS-2 403 transmits, to the UE B 407, a re-INVITE request (s) in which the SDP offer contains the media information of the data channel, application binding information, and the existing session ID with the other existing media descriptions. In one example embodiment, the IMS AS-2 403 may set the SIP header tag networkinitiator value as TRUE, and add the SIP header tag networkinitiator in the re-INVITE request (s) header. In a further example embodiment, the IMS AS-2 403 may add a=networkinitiator: yes as a new a-line in the SDP, and the IMS AS-2 403 sends the re-INVITE request (s) to the UE B 407. It should be noted that the DC media is set to on hold until step 440 is performed.
[0108] At 432, the UE B 407 may identify that the DC AS 401 from network side is the origin of the establishment request. The UE B 407 may decide to accept or reject the establishment request, e.g., based on the SIP header tag networkinitiator or the a-line a=networkinitiator in the SDP. Alternatively, the UE B 407 may alert the user to accept or reject the request manually. At 433, if the establishment request is rejected, the following steps may not be executed, and the UE B 407 may return a message to IMS AS-2 403 to reject the establishment request, e.g., SIP 607 Rejected.
[0109] At 434, a DC media negotiation may be performed, e.g., by using messages such as 18x, PRACK, 200 OK (PRACK) , UPDATE, and / or the like. After the DC media negotiation is completed, the UE B 407 may return a 200 OK response with an SDP answer for the application DC at 435.
[0110] At 436, the IMS AS-2 403 may transmit, to the UE A 409, a re-INVITE request (s) in which the SDP offer contains the media information of the data channel, application binding information, the existing session ID with the other existing media descriptions. In one example embodiment, the IMS AS-2 403 may set the SIP header tag networkinitiator value as TRUE, and add the SIP header tag networkinitiator in the re-INVITE request (s) header. Alternatively, the IMS AS-2 403 may add a=networkinitiator: yes as a new a-line in the SDP. Then, the IMS AS-2 403 sends the re-INVITE request (s) to the target UE A 409. It should be noted that the DC media may be set to on hold until step 440 is performed.
[0111] At 437, the UE A 409 may identify that the DC AS 401 from network side is the origin of the establishment request. The UE A 409 may decide to accept or reject the establishment request. Alternatively, the UE A 409 may alert the user to accept or reject the request manually. If the establishment request is rejected, the following steps may not be performed, and at 438, the UE A 409 may return a message to IMS AS-2 403 to reject the establishment request, e.g., SIP 607 Rejected.
[0112] At 440, the DC media negotiation and media resource information update may be performed. In some example embodiments, the DC media negotiation and media resource information update may be performed with operations similar to the steps 237-240 as shown in FIG. 2.
[0113] At 442, a session management update may be performed by IMS AS-2 403. In some example embodiments, the session management update may be performed with operations similar to the steps 241-244 as shown in FIG. 2.
[0114] The above-mentioned third solution will be described in detail with reference to FIG. 5, which illustrates a signaling chart 500 for validating user consent about DC AS initiated P2P ADC establishment request in accordance with some example embodiments of the present disclosure. In example embodiments discussed with respect to FIG. 5, UE A 509 and / or UE B 507 may be an example implementation of the apparatus 110 in FIG. 1, and the IMS AS-2 503 may be an example implementation of the network entity 120 in FIG. 1. It should be noted that the apparatus and the network entity may also be implemented in any other suitable manner. The scope of the present disclosure is not limited in this respect.
[0115] At 511, the UE B 507 may provide its user consent about the IMS DC establishment request at HSS-2 510. For example, the user consent may be about the acceptance or rejection of DC AS 501 as an initiator. Additionally or alternatively, the UE A 509 may also provide its user consent in its own network’s HSS. At 513, the HSS-2 510 may respond with the provisioning. It should be noted that although the above-mentioned provisioning process is described at first, this provisioning process may be performed at any time before step 522.
[0116] At 515, an IMS session between UE A 509 and UE B 507 may have been established, and a bootstrap DC has been also established. At 520, the DC AS 501 may request to add a P2P ADC between UE B 507 and UE A 509 to an existing IMS session. By way of the example, the step 520 may be implemented with operations similar to steps 220-223 as shown in FIG. 2.
[0117] At 522, the IMS AS-2 503 may receive the Nimsas_ImsSessionManagement_Update request from NEF 502, which may originate from the DC AS 501, instead of an SIP INVITE or SIP re-INVITE message from UE. Therefore, the IMS AS-2 503 may determine that the P2P ADC establishment request is initiated from the network side, not from the UE side.
[0118] At 523, the IMS AS-2 503 may validate the request based on the user consent data stored in the HSS-2 510. If the validation is successful, i.e., UE B 507 may accept the DC AS 501 initiated IMS DC establishment request, then the following steps are performed.
[0119] The IMS AS-2 503 may validate the user subscription data and check the IMS DC capability of UE and determines whether the data channel request should be notified to DCSF-2. If the serving UE does not have subscription of IMS data channel or does not have the IMS DC capability, then the request may be rejected with appropriate cause and the following steps may be skipped. Additionally or alternatively, if the same IMS data channel is already established, then the request shall be rejected with an appropriate cause and the following steps are skipped. If the IMS AS-2 503 allows the request to proceed, the IMS AS-2 503 may return a successful Nimsas_SessionManagement_Update response to the NEF 502 at 524.
[0120] At 524, if the validation of the user consent at 523 is not successful, i.e., the UE B 507 may not accept the DC AS 501 initiated IMS DC establishment request, the IMS AS-2 503 may return a failure Nimsas_SessionManagement_Update response to the NEF 502.
[0121] At 525, the NEF 502 may return a successful Nnef_SessionManagement_Update response to the DC AS 501. If the IMS AS-2 503 returns a failure Nimsas_SessionManagement_Update response to the NEF 502, then the NEF 502 may return a failure Nnef_SessionManagement_Update response to the DC AS 501 and the rest steps may be skipped.
[0122] At 530, one or more procedures, such as, session control and media control, SIP configuration towards UE B 507 and UE A 509, and optionally the session management notify, may be performed. In some example embodiments, these procedures may be performed with operations similar to steps 226-244 as shown in FIG. 2. Alternatively, these procedures may be performed with operations similar to steps 426-442 as shown in FIG. 4. The scope of the present disclosure is not limited in this respect.
[0123] It should be understood that although the proposed solutions are described above with reference to a specific use case of adding a P2P DC between UE B 507 and UE A 509 in an existing IMS session. The proposed solutions may also be used for other use cases, e.g., adding P2A2P and A2P DC in an existing IMS session, or creating standalone P2A2P and A2P DC, and / or the like. The scope of the present disclosure is not limited in this respect.
[0124] In view of the above, the proposed solution can advantageously make it possible to distinguish between UE-initiated IMS DC and application-initiated IMS DC. Thereby, the user can authorize the ADC establishment request with the knowledge of the real initiator, and thus the regulatory issue on user awareness can be mitigated.
[0125] FIG. 6 shows a flowchart of an example method 600 implemented at an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the apparatus 110 in FIG. 1.
[0126] At block 610, the apparatus 110 receives, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session. The request indicates that an initiator of the request is from network side, a third party or a user equipment.
[0127] At block 620, the apparatus 110 determines acceptance information about the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.
[0128] In view of the above, the apparatus 110 can distinguish the initiator of an IMS session to be established is from the network side, the UE side or a third party. Thus, the IMS session may be established in an efficient way.
[0129] In some example embodiments, the request may include an indication of the initiator, and a first value of the indication may indicate that the initiator is from network side or a third party, and a second value of the indication may indicate that the initiator is a user equipment, the first value being different from the second value.
[0130] Alternatively, in some example embodiments, presence of an indication of the initiator in the request may indicate that the initiator is from network side or a third party, and absence of the indication in the request may indicate that the initiator is a user equipment.
[0131] In either way discussed above, the information regarding the origin of the IMS session establishment request may be signaled in an efficient way.
[0132] In some example embodiments, the indication may be included in a header of the request, or comprised in a Session Description Protocol (SDP) section in a body of the request. Thus, the indication may be carried by the request in various ways.
[0133] In some example embodiments, the request may further include an identification of a further apparatus with which the IMS session is to be established. This identification may allow the user to be aware of the request initiator, then comply with privacy regulation and ethics rule such as transparency. Meanwhile, the indication of the initiator can be conveyed in a manner compatible to the existing communication protocol (s) .
[0134] In some example embodiments, the request may include a session initiation protocol (SIP) request message.
[0135] In some example embodiments, the acceptance information may be determined based on a policy of the apparatus. The policy may be for example a security policy or any other suitable policy. Based on the security policy, the apparatus 110 may decide to accept or reject the IMS session establishment request. Alternatively, the apparatus 110 may alert the user to accept or reject the request. According to the policy, the decision to accept or reject the request may be based on the identity of the other party provided in the request. If, for example, the identity of the other party is part of the user’s phone book, the user may decide to accept the request, otherwise reject the request. In this way, the acceptance information may be determined in a flexible way.
[0136] In some example embodiments, the apparatus 110 may further transmit, to a home subscriber server, data of the apparatus related to the establishment of an IMS session towards the apparatus. In some example embodiments, the data indicates at least one of: whether the apparatus accepts that the establishment of the IMS session is initiated from network side or from a third party, whether the apparatus accepts that the establishment of the IMS session is initiated from a user equipment, or information from which third party or user equipment the apparatus accepts the establishment of the IMS session. Thus, the data of the apparatus 110 related to the establishment of an IMS session may be prestored or recorded at the home subscriber server for further checking.
[0137] In some example embodiments, the apparatus 110 may, in accordance with a determination that the apparatus accepts the establishment of the IMS session, perform the establishment of the IMS session; and in accordance with a determination that the apparatus rejects the establishment of the IMS session, transmit to the network entity, information on rejection of the establishment of the IMS session.
[0138] In some example embodiments, the IMS session may include an IMS data channel session.
[0139] In some example embodiments, the apparatus may include a user equipment, the network entity may include an IMS application server, and the third party may include an external application server.
[0140] FIG. 7 shows a flowchart of an example method 700 implemented at a network entity in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the network entity 120 in FIG. 1.
[0141] At block 710, the network entity 120 determines whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment.
[0142] At block 720, the network entity 120 transmits, to the apparatus, a request for the establishment of the IMS session, the request indicating that an initiator of the request is from the network side, a third party or a user equipment.
[0143] In some example embodiments, the request may include an indication of the initiator. A first value of the indication may indicate that the initiator is from network side or a third party, and a second value of the indication may indicate that the initiator is a user equipment, the first value being different from the second value.
[0144] In some example embodiments, presence of an indication of the initiator in the request may indicate that the initiator is from network side or a third party, and absence of the indication in the request may indicate that the initiator is a user equipment.
[0145] In some example embodiments, the indication may be included in a header of the request, or comprised in a Session Description Protocol (SDP) section in a body of the request.
[0146] In some example embodiments, the request may further include an identification of a further apparatus with which the IMS session is to be established.
[0147] In some example embodiments, the request may include or may be a session initiation protocol (SIP) request message.
[0148] In some example embodiments, the network entity 120 may further receive, from the apparatus, information on rejection of the establishment of the IMS session.
[0149] In some example embodiments, the network entity 120 may, in response to receiving, from a further network entity comprises a network exposure function (NEF) or a data channel application server, a further request associated with the establishment of the IMS session, determine that the establishment of the IMS session is initiated from network side or a third party; and in response to receiving, from a further apparatus, a message associated with the establishment of the IMS session, determine that the establishment of the IMS session is initiated from a user equipment.
[0150] In some example embodiments, the network entity 120 may further obtain, from a home subscriber server, data of the apparatus related to the establishment of an IMS session towards the apparatus; and in accordance with a determination that the request for the establishment of the IMS session is validated based on the data of the apparatus, transmit the request to the apparatus.
[0151] In some example embodiments, the data may indicate at least one of: whether the apparatus accepts that the establishment of the IMS session is initiated from network side or from a third party, whether the apparatus accepts that the establishment of the IMS session is initiated from a user equipment, or information from which third party or user equipment the apparatus accepts the establishment of the IMS session.
[0152] In some example embodiments, the IMS session may include an IMS data channel session.
[0153] In some example embodiments, the apparatus may include a user equipment, the network entity may include an IMS application server, and the third party may include an external application server.
[0154] In some example embodiments, an apparatus capable of performing any of the method 600 (for example, the apparatus 110 in FIG. 1) may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the apparatus 110 in FIG. 1.
[0155] In some example embodiments, the apparatus comprises means for receiving, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; and means for determining acceptance information about the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.
[0156] In some example embodiments, the request comprises an indication of the initiator, and wherein a first value of the indication indicates that the initiator is from network side or a third party, and a second value of the indication indicates that the initiator is a user equipment, the first value being different from the second value.
[0157] In some example embodiments, presence of an indication of the initiator in the request indicates that the initiator is from network side or a third party, and absence of the indication in the request indicates that the initiator is a user equipment.
[0158] In some example embodiments, the indication is comprised in a header of the request, or comprised in a Session Description Protocol (SDP) section in a body of the request.
[0159] In some example embodiments, the request further comprises an identification of a further apparatus with which the IMS session is to be established.
[0160] In some example embodiments, the request comprises a session initiation protocol (SIP) request message.
[0161] In some example embodiments, the acceptance information is determined based on a policy of the apparatus.
[0162] In some example embodiments, the apparatus further comprises: means for transmitting, to a home subscriber server, data of the apparatus related to the establishment of an IMS session towards the apparatus.
[0163] In some example embodiments, the data indicates at least one of: whether the apparatus accepts that the establishment of the IMS session is initiated from network side or from a third party, whether the apparatus accepts that the establishment of the IMS session is initiated from a user equipment, or information from which third party or user equipment the apparatus accepts the establishment of the IMS session.
[0164] In some example embodiments, the apparatus further comprises: means for in accordance with a determination that the apparatus accepts the establishment of the IMS session, performing the establishment of the IMS session; and means for in accordance with a determination that the apparatus rejects the establishment of the IMS session, transmitting to the network entity, information on rejection of the establishment of the IMS session.
[0165] In some example embodiments, the IMS session comprises an IMS data channel session.
[0166] In some example embodiments, the apparatus comprises a user equipment, the network entity comprises an IMS application server, and the third party comprises an external application server.
[0167] In some example embodiments, a network entity capable of performing any of the method 700 (for example, the network entity 120 in FIG. 1) may comprise means for performing the respective operations of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The network entity may be implemented as or included in the network entity 120 in FIG. 1.
[0168] In some example embodiments, the network entity comprises means for determining whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; and means for transmitting, to the apparatus, a request for the establishment of the IMS session, the request indicating that an initiator of the request is from the network side, a third party or a user equipment.
[0169] In some example embodiments, the request comprises an indication of the initiator, and wherein a first value of the indication indicates that the initiator is from network side or a third party, and a second value of the indication indicates that the initiator is a user equipment, the first value being different from the second value.
[0170] In some example embodiments, presence of an indication of the initiator in the request indicates that the initiator is from network side or a third party, and absence of the indication in the request indicates that the initiator is a user equipment.
[0171] In some example embodiments, the indication is comprised in a header of the request, or comprised in a Session Description Protocol (SDP) section in a body of the request.
[0172] In some example embodiments, the request further comprises an identification of a further apparatus with which the IMS session is to be established.
[0173] In some example embodiments, the request comprises a session initiation protocol (SIP) request message.
[0174] In some example embodiments, the network entity further comprises: means for receiving, from the apparatus, information on rejection of the establishment of the IMS session.
[0175] In some example embodiments, the network entity further comprises: means for in response to receiving, from a further network entity comprises a network exposure function (NEF) or a data channel application server, a further request associated with the establishment of the IMS session, determine that the establishment of the IMS session is initiated from network side or a third party; and means for in response to receiving, from a further apparatus, a message associated with the establishment of the IMS session, determine that the establishment of the IMS session is initiated from a user equipment.
[0176] In some example embodiments, the network entity further comprises: means for obtaining, from a home subscriber server, data of the apparatus related to the establishment of an IMS session towards the apparatus; and means for in accordance with a determination that the request for the establishment of the IMS session is validated based on the data of the apparatus, transmitting the request to the apparatus.
[0177] In some example embodiments, the data indicates at least one of: whether the apparatus accepts that the establishment of the IMS session is initiated from network side or from a third party, whether the apparatus accepts that the establishment of the IMS session is initiated from a user equipment, or information from which third party or user equipment the apparatus accepts the establishment of the IMS session.
[0178] In some example embodiments, the IMS session comprises an IMS data channel session.
[0179] In some example embodiments, the apparatus comprises a user equipment, the network entity comprises an IMS application server, and the third party comprises an external application server.
[0180] FIG. 8 is a simplified block diagram of a device 800 that is suitable for implementing example embodiments of the present disclosure. The device 800 may be provided to implement a communication device, for example, the apparatus 110 or the network entity 120 as shown in FIG. 1. As shown, the device 800 includes one or more processors 810, one or more memories 820 coupled to the processor 810, and one or more communication modules 840 coupled to the processor 810.
[0181] The communication module 840 is for bidirectional communications. The communication module 840 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 840 may include at least one antenna.
[0182] The processor 810 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 800 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
[0183] The memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 824, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 822 and other volatile memories that will not last in the power-down duration.
[0184] A computer program 830 includes computer executable instructions that are executed by the associated processor 810. The instructions of the program 830 may include instructions for performing operations / acts of some example embodiments of the present disclosure. The program 830 may be stored in the memory, e.g., the ROM 824. The processor 810 may perform any suitable actions and processing by loading the program 830 into the RAM 822.
[0185] The example embodiments of the present disclosure may be implemented by means of the program 830 so that the device 800 may perform any process of the disclosure as discussed with reference to FIG. 3 to FIG. 7. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
[0186] In some example embodiments, the program 830 may be tangibly contained in a computer readable medium which may be included in the device 800 (such as in the memory 820) or other storage devices that are accessible by the device 800. The device 800 may load the program 830 from the computer readable medium to the RAM 822 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .
[0187] FIG. 9 shows an example of the computer readable medium 900 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 900 has the program 830 stored thereon.
[0188] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
[0189] Some example embodiments of the present 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 included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.
[0190] Program code for carrying out methods of the present 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 the program code, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
[0191] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.
[0192] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0193] Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.
[0194] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims
1.An apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:receive, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; anddetermine acceptance information about the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.2.The apparatus of claim 1, wherein the request comprises an indication of the initiator, andwherein a first value of the indication indicates that the initiator is from network side or a third party, and a second value of the indication indicates that the initiator is a user equipment, the first value being different from the second value.3.The apparatus of claim 1, wherein presence of an indication of the initiator in the request indicates that the initiator is from network side or a third party, and absence of the indication in the request indicates that the initiator is a user equipment.4.The apparatus of claim 2 or 3, wherein the indication is comprised in a header of the request, or comprised in a Session Description Protocol (SDP) section in a body of the request.5.The apparatus of any of claims 1 to 4, wherein the request further comprises an identification of a further apparatus with which the IMS session is to be established.6.The apparatus of any of claims 1 to 5, wherein the request comprises a session initiation protocol (SIP) request message.7.The apparatus of any of claims 1 to 6, wherein the acceptance information is determined based on a policy of the apparatus.8.The apparatus of any of claims 1 to 7, wherein the apparatus is caused to:transmit, to a home subscriber server, data of the apparatus related to the establishment of an IMS session towards the apparatus.9.The apparatus of claim 8, wherein the data indicates at least one of:whether the apparatus accepts that the establishment of the IMS session is initiated from network side or from a third party,whether the apparatus accepts that the establishment of the IMS session is initiated from a user equipment, orinformation from which third party or user equipment the apparatus accepts the establishment of the IMS session or for which data channel applications the apparatus accepts network initiated IMS session establishment.10.The apparatus of any of claims 1 to 9, wherein the apparatus is caused to:in accordance with a determination that the apparatus accepts the establishment of the IMS session, perform the establishment of the IMS session; andin accordance with a determination that the apparatus rejects the establishment of the IMS session, transmit, to the network entity, information on rejection of the establishment of the IMS session.11.The apparatus of any of claims 1 to 10, wherein the IMS session comprises an IMS data channel session.12.The apparatus of any of claims 1 to 11, wherein the apparatus comprises a user equipment, the network entity comprises an IMS application server, and the third party comprises an external application server.13.A network entity comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the network entity at least to:determine whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; andtransmit, to the apparatus, a request for the establishment of the IMS session, the request indicating that an 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 comprises an indication of the initiator, andwherein a first value of the indication indicates that the initiator is from network side or a third party, and a second value of the indication indicates that the initiator is a user equipment, the first value being different from the second value.15.The network entity of claim 13, wherein presence of an indication of the initiator in the request indicates that the initiator is from network side or a third party, and absence of the indication in the request indicates that the initiator is a user equipment.16.The network entity of claim 14 or 15, wherein the indication is comprised in a header of the request, or comprised in a Session Description Protocol (SDP) section in a body of the request.17.The network entity of any of claims 13 to 16, wherein the request further comprises an identification of a further apparatus with which the IMS session is to be established.18.The network entity of any of claims 13 to 17, wherein the request comprises a session initiation protocol (SIP) request message.19.The network entity of any of claims 13 to 18, wherein the network entity is caused to:receive, from the apparatus, information on rejection of the establishment of the IMS session.20.The network entity of any of claims 13 to 19, wherein the network entity is caused to:in response to receiving, from a further network entity comprises a network exposure function (NEF) or a data channel application server, a further request associated with the establishment of the IMS session, determine that the establishment of the IMS session is initiated from network side or a third party; andin response to receiving, from a further apparatus, a message associated with the establishment of the IMS session, determine that the establishment of the IMS session is initiated from a user equipment.21.The network entity of any of claims 13 to 20, wherein the network entity is caused to:obtain, from a home subscriber server, data of the apparatus related to the establishment of an IMS session towards the apparatus; andin accordance with a determination that the request for the establishment of the IMS session is validated based on the data of the apparatus, transmit the request to the apparatus.22.The network entity of claim 21, wherein the data indicates at least one of:whether the apparatus accepts that the establishment of the IMS session is initiated from network side or from a third party,whether the apparatus accepts that the establishment of the IMS session is initiated from a user equipment, orinformation from which third party or user equipment the apparatus accepts the establishment of the IMS session or for which data channel applications the apparatus accepts network initiated IMS session establishment.23.The network entity of any of claims 13 to 22, wherein the IMS session comprises an IMS data channel session.24.The network entity of any of claims 13 to 23, wherein the apparatus comprises a user equipment, the network entity comprises an IMS application server, and the third party comprises an external application server.25.A method comprising:receiving, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; anddetermining acceptance information about the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.26.A method comprising:determining whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; andtransmitting, to the apparatus, a request for the establishment of the IMS session, the request indicating that an initiator of the request is from the network side, a third party or a user equipment.27.An apparatus comprising:means for receiving, from a network entity, a request for an establishment of an IP Multimedia Subsystem (IMS) session, the request indicating that an initiator of the request is from network side, a third party or a user equipment; andmeans for determining acceptance information about the establishment of the IMS session based on the initiator, the acceptance information indicating whether the apparatus accepts the establishment of the IMS session.28.A network entity comprising:means for determining whether an establishment of an IP Multimedia Subsystem (IMS) session with an apparatus is initiated from network side, a third party or a user equipment; andmeans for transmitting, to the apparatus, a request for the establishment of the IMS session, the request indicating that an 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 for causing an apparatus at least to perform the method of claim 25 or the method of claim 26.