TECHNICAL FIELD

[0001] Disclosed are embodiments related to a method and system for reporting and using location information of multiple user equipments (UEs) of a subscriber, e.g. reporting to and using by a communication control node.

BACKGROUND

[0002] The 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 22.173 describes multimedia telephony service and supplementary services, and defines the support of multiple UEs in the Internet Protocol (IP) Multimedia Core Network Subsystem (IMS).

[0003] The 3GPP TS 24.174 describes support of multi-device and multi -identity in the IMS, and introduces the Multi-Device (MuD) service, which is an operator specific service that enables a user to use multiple UEs that are registered under the same public user identity. The UEs can be of different types (e.g. phone, tablet, wearable device, PC).

[0004] Other relevant 3GPP TS include: TS 32.240, describing telecommunication management, charging management, and charging architecture and principles; TS 32.260, describing telecommunication management, charging management, and IMS charging; and TS 32.299, describing telecommunication management, charging management, and diameter charging applications.

SUMMARY

[0005] When more than one UE is connected to an IMS subscription, the Application Server (AS) will distribute the incoming communication to one or more UEs of the subscriber, depending on the terminating AS service policy. The communication can then be answered by any of the alerted UEs. In the initial charging data request from the terminating AS, location information of one UE (e.g., the primary, default, or operator defined UE) can be reported to the online charging system (OCS). It is currently only possible to report the location of one UE. This means the UE answering the communication may not be same as the UE whose location was included in initial charging data request. In addition, the location of the UE answering the communication may be different from the location reported in the initial charging data request.

[0006] Further, once the communication is answered, the online charging system can be updated with the location information of the answering UE. Hence, in the current mechanism, the actual location of the answering UE is not available until the communication is established. This leads to a problem in executing location-based policies in the online charging system, especially when the online charging system decides to reject the communication, as that may result in a “ghost call” - i.e., when communication is disconnected when the called party answers the call.

[0007] Another example occurs with an External Caller Treatment and Category (ECTC) Application or an External Call Control (ECC) Application, where the lack of information about a called party’s multiple UEs can impose limitations in executing call control policies. A possible use case is when the ECTC Application qualifies the caller as not trustworthy and decides to alert only specific UEs of the called party.

[0008] Therefore, there is need for a method and system that allow reporting of location and identity information of multiple UEs of a subscriber to a communication controller node (CCN), such as a CS, an ECTC Application, or an ECC Application. Embodiments provide a method of or system for conveying location of multiple UEs of a subscriber to a CCN (e.g., a CS, ECTC Application, or ECC Application) by an AS when the subscriber is participating in communication setup or mid-call multimedia telephony service execution.

[0009] Enhancement in reporting towards a CCN (e.g., a CS, ECTC Application, or ECC Application) is one possible approach to influence call control policy execution in the CCN. For such enhanced reporting, in embodiments, the AS may report all (or a subset of) the UEs of the subscriber towards the CCN, including identity information and location information about the UEs. For example, the AS may report information about all (or a subset) of UEs of the subscriber that will participate in the communication setup or in the mid-call multimedia telephony service execution. This reporting facilitates enhanced communication policy control, e.g. by allowing and disallowing communication distribution per UE of the subscriber. In embodiments, such reporting about multiple UEs may take place in a single message. [0010] The conveyed information also enables the CCN to visualize the holistic view of the UEs of a subscriber and their respective locations. For example, when the CCN is a CS, by enabling location-based policies execution the CS may charge the subscriber more appropriately, e.g., during communication setup or when performing mid-call multimedia telephony service execution. More generally, the holistic view that is provided by this information can improve existing business logic as well as allow for new location-based policies. For example, one policy that could be supported, would be not allowing pushing of a communication from a UE in 5G access to another UE in circuit switched access of the same subscriber because of an operator’s 5G deployment restriction.

[0011] Another advantage of embodiments is that network resources may be more efficiently utilized by only distributing calls to relevant UEs. For example, the CCN may have better control on subscriber consolidated roaming status, based on the location of the various UEs of a subscriber. In the context of the CCN being a CS, embodiments allow an operator to avoid many loopholes of current charging data reporting by tracking the location of the subscriber’s UEs continuously via various communications. Embodiments may also lead to less network signaling and enhance user experience (e.g., by avoiding ghost calls).

[0012] Embodiments disclosed herein are applicable to use-cases where operators of a telecommunication system support multi-UE deployment for a subscriber. Also, automobile or chip-set vendors may be able to take advantage of embodiments, e.g. by allowing users to push active communication from a car phone to a smart phone or pull active communication to a car phone from a smart phone. Embodiments disclosed herein are applicable to all kinds of UEs, including SIM and non-SIM UEs, and for both registered and unregistered Voice over Long- Term Evolution (VoLTE)/Voice over New Radio (VoNR) UEs and also UEs on circuit switched access. Further, embodiments are applicable for postpaid as well as prepaid charging systems.

[0013] According to a first aspect, a method performed by an application server in communication with a communication controller node is provided. The method includes sending, by the application server, a first control data request toward the communication controller node. The first control data request is for a call-related service involving a first user agent and a second user agent. The first control data request comprises identity information and location information for a plurality of user equipments (UEs) associated with the second user agent. The method includes receiving, by the application server, a first control data response comprising result information for each of the plurality of UEs associated with the second user agent included in the first control data request. The method includes processing the call-related service based on the first control data response.

[0014] In some embodiments, the application server comprises an IP Multimedia Subsystem (IMS) Telephony Application Server (TAS). In some embodiments, the communication controller node comprises one of an online charging system, an External Call Control (ECC) Application, an External Caller Treatment and Category (ECTC) Application. In some embodiments, the communication controller node comprise an online charging system and the first control data request comprises a charging data request. In some embodiments, the identity information for the plurality of UEs associated with the second user agent comprises, for each UE of the plurality of UEs, a distinct UE identifier associated with the UE. In some embodiments, the distinct UE identifier comprises an Internet Protocol (IP) Multimedia Private Identity (IMPI). In some embodiments, the identity information for the plurality of UEs associated with the second user agent further comprises one or more of (i) a UE role, (ii) source information related to the identity information, and (iii) a UE type, associated with each of the plurality of UEs.

[0015] In some embodiments, the location information for the plurality of UEs associated with the second user agent comprises one or more of (i) an access network information (ANI) and (ii) a geographical location. In some embodiments, the location information further comprises one or more of (i) source information related to the location information and (ii) an age of the location information indicating when the location information was provided or verified. In some embodiments, the method further includes collecting the identity information and location information for the plurality of UEs associated with the second user agent. In some embodiments, collecting the identity information and location information for the plurality of UEs associated with the second user agent comprises one or more of (i) receiving the identity information and location information from one or more of the plurality of UEs; and (ii) requesting the identity information and location information from a network node. In some embodiments, the network node comprises a Home Subscriber Server (HSS). [0016] In some embodiments, the call-related service involving the first user agent and the second user agent comprises a communication setup request initiated by the first user agent. The method further includes determining, by the application server, a subset of allowed UEs of the plurality of UEs associated with the second user agent based on the result information in the first control data response. The method further includes sending, by the application server, a communication setup request message toward each of the allowed UEs in the subset of allowed UEs. The method further includes receiving, by the application server, an answer from an answering UE in the subset of allowed UEs. The method further includes canceling, by the application server, communication to each of the non-answering UEs in the subset of allowed UEs. In some embodiments, the method further includes sending, by the application server, a second control data request toward the communication controller node. The second control data request comprises identity information and location information of both the answering UE and a primary UE associated with the second user agent. The method further includes receiving, by the application server, a second control data response.

[0017] In some embodiments, the call-related service involving the first user agent and the second user agent comprises a communication transfer request from a participating UE of the second user agent requesting a transfer to other UEs of the second user agent. The method further includes determining, by the application server, a subset of allowed UEs of the plurality of UEs associated with the second user agent based on the result information in the first control data response. The method further includes sending, by the application server, a communication transfer message toward each of the allowed UEs in the subset of allowed UEs. The method further includes receiving, by the application server, an answer from an answering UE in the subset of allowed UEs. The method further includes canceling, by the application server, communication to each of the non-answering UEs in the subset of allowed UEs. In some embodiments, the method further includes sending, by the application server, a second control data request toward the communication controller node. The second control data request comprises identity information and location information of the answering UE and the UE that initiated the communication transfer request. The method further includes receiving, by the application server a second control data response. [0018] In some embodiments, the call-related service involving the first user agent and the second user agent comprises a communication transfer request from a non-participating UE of the second user agent requesting a transfer from a participating UE of the second user agent. The method further includes determining, by the application server, whether the requesting UE is allowed to be transferred the pending communication based on the result information in the first control data response. The method further includes, if it is determined that the requesting UE is allowed to be transferred the communication, (i) sending, by the application server, a communication transfer message toward the participating UE; and otherwise (ii) sending, by the application server, a failure message toward the requesting UE.

[0019] In some embodiments, the communication controller node comprises an External Caller Treatment and Category (ECTC) Application, and the result information for each of the plurality of UEs is based on a trustworthiness determination about the first user agent.

[0020] According to a second aspect, a method performed by a communication controller node in communication with an application server is provided. The method includes receiving, by the communication controller node, a first control data request from the application server. The first control data request is for a call-related service involving a first user agent and a second user agent. The first control data request comprises identity information and location information for a plurality of user equipments (UEs) associated with the second user agent. The method includes determining result information for each of the plurality of UEs associated with the second user agent included in the first control data request based on the identity information and location information for the plurality of UEs. Such result information indicates whether communication to a particular UE is allowed. The method includes sending, by the communication controller node, a first control data response toward the application server, wherein the first control data response comprises the result information for each of the plurality of UEs associated with the second user agent included in the first control data request.

[0021] According to a third aspect, an application server is provided. The application server includes processing circuitry. The application server includes a memory, the memory containing instructions executable by the processing circuitry. When the instructions are executed the processing circuitry is configured to send, by the application server, a first control data request toward the communication controller node. The first control data request is for a call-related service involving a first user agent and a second user agent. The first control data request comprises identity information and location information for a plurality of user equipments (UEs) associated with the second user agent. When the instructions are executed the processing circuitry is configured to receive, by the application server, a first control data response comprising result information for each of the plurality of UEs associated with the second user agent included in the first control data request. When the instructions are executed the processing circuitry is configured to process the call-related service based on the first control data response.

[0022] According to a fourth aspect, a communication controller node is provided. The application server includes processing circuitry. The application server includes a memory, the memory containing instructions executable by the processing circuitry. When the instructions are executed the processing circuitry is configured to receive, by the communication controller node, a first control data request from the application server. The first control data request is for a call-related service involving a first user agent and a second user agent. The first control data request comprises identity information and location information for a plurality of user equipments (UEs) associated with the second user agent. When the instructions are executed the processing circuitry is configured to determine result information for each of the plurality of UEs associated with the second user agent included in the first control data request based on the identity information and location information for the plurality of UEs. Such result information indicates whether communication to a particular UE is allowed. When the instructions are executed the processing circuitry is configured to send, by the communication controller node, a first control data response toward the application server. The first control data response comprises the result information for each of the plurality of UEs associated with the second user agent included in the first control data request.

[0023] According to a fifth aspect, a computer program is provided, comprising instructions which when executed by the processing circuitry of a node cause the node to perform the method of any of the embodiments of the first or second aspects.

[0024] According to a sixth aspect, a carrier is provided, containing the computer program of the fifth aspect. The carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0026] FIG. 1 illustrates a system according to an embodiment.

[0027] FIG. 2 illustrates a sequence diagram according to an embodiment.

[0028] FIG. 3 illustrates a sequence diagram according to an embodiment.

[0029] FIG. 4 illustrates a sequence diagram according to an embodiment.

[0030] FIG. 5 illustrates a sequence diagram according to an embodiment.

[0031] FIG. 6 illustrates a sequence diagram according to an embodiment.

[0032] FIG. 7 illustrates a sequence diagram according to an embodiment.

[0033] FIG. 8 illustrates a flowchart according to an embodiment.

[0034] FIG. 9 illustrates a flowchart according to an embodiment.

[0035] FIG. 10 is a block diagram of an apparatus according to an embodiment.

DETAILED DESCRIPTION

[0036] FIG. 1 illustrates a system 100 according to an embodiment. As shown, system 100 (e.g., a communication system employing a network communication protocol such as 3G, 4G, or 5G) includes a first user agent (UA) 102, a second UA 104, an AS 106, an OCS 108, a Home Subscriber Server (HSS) 110, an ECTC Application 112, and an ECC Application 114.

As shown, UA 102 (referred to as UA-A) has UE 102a (referred to as UE-A1) associated with it, though in embodiments UA 102 may also have other associated UEs. As shown, UA 104 (referred to as UA-B) has UEs 104a-104d (referred to as UE-B1 - UE-B4) associated with it, though in embodiments UA 104 may have either fewer or more associated UEs. For example, UE-B1 may be a smart phone, a SIM device, on LTE access, and the primary UE associated with UA-B; UE-B2 may be a car phone, a SIM device, on 5G NR access, and a secondary (or nonprimary) UE associated with UA-B; UE-B3 may be a PDA, a non-SIM device, on WLAN, and a secondary (or non-primary) UE associated with UA-B; and UE-B4 may be another smart phone, a SIM device, on circuit switched access, and a secondary (or non-primary) UE associated with UA-B.

[0037] Each of UA 102, UA 104, OCS 108, HSS 110, ECTC Application 112, and ECC Application 114 may communicate with AS 106. This communication may be direct, or may be intermediated by other nodes (not shown). There may be other communication pathways between these elements that are not shown, and there may be other elements that are part of the system 100. For example, there may be multiple ASs 106, and each of the multiple ASs 106 may be able to communicate with each other. As another example, system 100 may include each of the nodes needed for a 5G communication system using NR.

[0038] In embodiments, AS 106 may be an IMS Telephony Application Server (TAS). An IMS TAS offers value added IM services and resides either in the user’s home network. It is a multimedia telephony application server for voice and multimedia. A TAS is a Session Initiation Protocol (SIP) Application Server specified within 3GPP that supports IMS reference points (e.g., an IMS Service Control (ISC) interface, an Sh interface, or a Ro/Rf (possibly a representational state transfer (REST) interface), in support of an application, and is considered part of the IM CN subsystem. 3GPP TS 23.002 V15.0.0, describing network architecture, provides further details.

[0039] In embodiments, the ECTC Application 112 is a network element that provides third party call treatment verdicts per calling party category identified by an analytics function or by the operator, over an HTTP or SIP interface to the AS 106. It may also provide categorization information of the calling party along with their reputation levels to the AS 106.

[0040] In embodiments, ECC Application 114 is a network element that provides third party call treatment functions via a RESTful interface. ECC Application 144 may use Call Direction service capabilities exposed by an AS node in the Communication Service Provider’s network. The ECC Application 114 processes the incoming CallNotification (CallDirection) request from the AS 106 and provides a response to it for further call progress, e.g., whether to continue, route, or end the call.

[0041] AS 106 may collect identity information and location information of different UEs interacting with it, e.g. UEs 102a and 104a-104d, and include such identity information and location information in messaging to a CCN (e.g., OCS 108, ECTC Application 112, or ECC Application 114). In embodiments, identity information may be obtained from one or more of: UE SIP Registration and subscriber transparent data stored in HSS 110. In embodiments, location information may be obtained from one or more of: UE SIP Registration, communication setup signaling, HSS 110, and other IMS nodes (e.g., a Call Session Control Function (CSCF) node).

[0042] In embodiments, UE identity information may include one or more of:

• A UE identity: One of the possible approaches to identify subscriber UEs uniquely is via a distinct identifier, such as by using an IP Multimedia Private Identity (IMPI) value. In embodiments, this is a mandatory element of the identity information that is shared with a CCN by AS 106.

• A UE role: The role of the UE, e.g., primary UE, secondary UE, default UE, operator defined UE, and so on. In embodiments, this is an optional element of the identity information that is shared with a CCN by AS 106.

• A UE identity source: This identifies the source of the UE identity information. The source can help the AS 106 or the CCN to decide the reliability of the identity provided. In embodiments, the source may be, e.g. SIP Registration, HSS, Ut Interface, and so on. In embodiments, this is an optional element of the identity information that is shared with a CCN by AS 106.

• A UE type: This identifies the type of the UE. For example, the type may be a SIM device or a Non-SIM device. In embodiments, this is an optional element of the identity information that is shared with a CCN by AS 106.

[0043] In embodiments, UE location information may include one or more of:

• A location: One of the possible approaches to determine the location of a UE is via Access Network Information (ANI). For example, ANI may be indicated indirectly via (i) a cell global identity, in case of cellular radio access or (ii) an IP address and port, in case of WLAN access, or may be indicated directly via an operator-specific geographical identifier. It can also contain the information such as whether it is provided by the network or the user. In embodiments, this is a mandatory element of the location information that is shared with a CCN by AS 106.

• A location source: This identifies the source of the UE location information. The source can help the AS 106 or the CCN to decide the reliability of the location provided. In embodiments, the source may be, e.g. AS (stored in AS 106, e.g. from SIP registration), communication signaling (e.g., received in SIP communication signaling), HSS nontransparent data (e.g., fetched from HSS 110 as part of non-transparent data of a subscriber), HSS transparent data (e.g., fetched from HSS 110 as part of transparent data of a subscriber), or another IMS node (e.g., received from another IMS node, such as the CSCF node). In embodiments, this is an optional element of the location information that is shared with a CCN by AS 106.

• An age of the location: An age (e.g., a timestamp) can be provided, if available, to show the accuracy of the location. It is optional element. In embodiments, this is an optional element of the location information that is shared with a CCN by AS 106. [0044] An example of the types of location and identity information that may be provided by AS 106 to a CCN is shown below: In the table above, “NP” stands for network provided, and “UP” stands for user provided.

[0045] A CCN may also influence the service execution in AS 106 by providing results for one or more UEs of a subscriber in a control data response to AS 106 (e.g., a charging data response in context of an online charging system). AS 106 can consider the result for controlling the communication towards a particular UE.

[0046] For example, a CCN may report results to AS 106 as in the following example. A result value could be, e.g., allowed or blocked. When a result value is not present for one or more UEs, the AS 106 may execute the communication as per AS-specific service policy.

Allowed indicates that the communication to the UE is allowed. Blocked indicates that the communication to the UE is blocked. Other possible result values may also be used.

[0047] An example of the types of results that may be provided by a CCN to AS 106 is shown below:

[0048] Embodiments disclosed herein are applicable to a wide array of uses cases. As non-limiting examples, consider the following. A subscriber can be provisioned with multiple additional identities shared among multiple UEs. On an incoming call to a specific identity of such a subscriber, only the UEs, and their locations, which are associated with that identity are reported to a CCN before they are alerted. Based on an operator specific location-based policy, the CCN can allow or block the communication distribution to one or more of those UEs.

Similarly, embodiments are applicable in a communication transfer request (e.g., push/pull scenarios), where location information of the current and requesting UEs are reported to a CCN by the AS. This can help the CCN to act appropriately for a given subscriber (e.g., for an online charging system, to appropriately charge the subscriber).

[0049] FIG. 2 illustrates a sequence diagram according to an embodiment. As shown, UEs 104a-104d, AS 106, and HSS 110 may communicate with each other. The numbered items 1-7 below correspond to the numbered items shown in FIG. 2. In the sequence shown in FIG. 2, AS 106 discovers identity and location information for multiple UEs (UE-B1 - UE-B4) of a subscriber (UA-B).

[0050] For descriptive purposes, the following is assumed. UA-B is an IMS subscriber (e.g., “Bob”), and has 4 devices: a smart phone (UE-B1), a car phone (UE-B2), a PDA (UE-B3), and another smart phone (UE-B4). IMS subscriber Bob (UA-B) is served by AS 106 in a multidevice deployment.

[0051] Step 1 : Bob’s smart phone (UE-B1) performs IMS Registration using an LTE access, as shown at 201.

[0052] Step 2: AS 106 fetches Bob ’s service data for HSS 110 (e.g. from HSS 110), as shown at 202. AS 106 learns the identity of multiple UEs of Bob from the fetched transparent service data and the location of Bob’s smart phone (UE-B1) from the IMS registration message, as shown at 203.

[0053] Step 3: AS 106 acknowledges the successful IMS registration of Bob’s smart phone (UE-B1), as shown at 204.

[0054] Step 4: Bob’s car phone (UE-B2) performs IMS Registration using a 5G access, as shown at 205. AS 106 learns the location of the car phone (UE-B2) from the IMS registration message, as shown at 209.

[0055] Step 5: AS 106 acknowledges the successful IMS registration of Bob’s car phone (UE-B2), as shown at 206.

[0056] Step 6: Bob’s PDA (UE-B3) performs IMS Registration using a WLAN access, as shown at 207. AS 106 learns the location of the PDA (UE-B3) from the IMS registration message, as shown at 209. [0057] Step 7: AS 106 acknowledges the successful IMS registration of Bob’s PDA (UE- B3), as shown at 208.

[0058] Following this, AS 106 has now learned the identity and location of most of the UEs (i.e., UE-B1, UE-B2, and UE-B3) of the served user Bob (UA-B), and has learned the identity of the remaining UE (i.e., UE-B4) of the served user Bob (UA-B), as shown at 208.

[0059] FIG. 3 illustrates a sequence diagram according to an embodiment. As shown, UE 102a, AS 106, UEs 104a-104d, HSS 110, and OCS 108 may communicate with each other. The numbered items 1-13 below correspond to the numbered items shown in FIG. 3. In the sequence shown in FIG. 3, AS 106 handles a terminating communication where OCS 108 influences the communication distribution. Although the example is provided in the context of OCS 108, other types of CCN are also applicable.

[0060] As before, IMS subscriber Bob (UA-B) has 4 devices: a smart phone (UE-B1), a car phone (UE-B2), a PDA (UE-B3), and another smart phone (UE-B4). IMS subscriber Bob (UA-B) is served by AS 106 in a multi-device deployment.

[0061] Served user Bob’s devices UE-B1, UE-B2, and UE-B3 are IMS registered, as shown at 301.

[0062] AS 106 has learned identity and location information of most of the UEs of served user Bob (UA-B), as shown at 302. For example, this could happen in the sequence diagram illustrated and described with respect to FIG. 2.

[0063] Step 1 : AS 106 of served user Bob (UA-B) receives a terminating communication request from caller UA-A using an LTE access, as shown at 303.

[0064] Step 2: Since AS 106 does not have location information for UE-B4, it fetches it from HSS 110, as shown at 304.

[0065] Step 3: HSS 110 acknowledges the AS 106 request, and indicates the location information for UE-B4 (here, for example, that it is circuit switched access), as shown at 305.

[0066] Step 4: AS 106 sends a charging data request for a communication setup request for Bob, as shown at 306. The charging data request contains the identity and location information of multiple UEs of Bob’s, as shown at 307. [0067] Step 5: OCS 108 executes enhanced location-based policy service on the AS 106 provided identity and location information of Bob’s multiple UEs, as shown at 308. In this example, communication to UE-B4 (circuit switched access) is blocked, e.g. due to an operator specific regulatory feature for UEs on circuit switched access, while communication towards rest of the UEs is allowed. This result is send to AS 106 with the charging data result, as shown at 309. The charging data result contains the results for each of UE-B1 - UE-B4, as shown at 310.

[0068] Step 6 - Step 8: AS 106 distributes the communication to allowed UEs, as shown at 311-313.

[0069] Step 9: Bob answers the communication using UE-B2, as shown at 314.

[0070] Step 10: AS 106 Cancels communication towards UE-B1 and UE-B3, as shown at

315.

[0071] Step 11 : AS 106 sends a charging data request to OCS 108, containing identity and location information of the answering UE (UE-B2), as shown at 316. The charging data request may also contain identity and location information of Bob’s primary UE (here, UE-B1), if it is different than the answering UE, as shown at 317. By this point, AS 106 contains the identity and location information for all of Bob’s UEs, as shown at 318. For example, the location information for UE 104b (UE-B2) may have been updated by the AS 106 based on information received when that UE answered the communication at 314.

[0072] Step 12: OCS 108 acknowledges the answering UE (UE-B2), its valid location, and allows the communication setup, as shown at 319. In response, OCS 108 sends a successful charging data response, as shown at 320.

[0073] Step 13: Communication setup continues, as shown at 321.

[0074] FIG. 4 illustrates a sequence diagram according to an embodiment. As shown, UE 102a, AS 106, UEs 104a-104d, HSS 110, and OCS 108 may communicate with each other. The numbered items 1-9 below correspond to the numbered items shown in FIG. 4. In the sequence shown in FIG. 4, AS 106 handles a communication transfer request from a participating UE of Bob’s requesting a transfer to another UE of Bob’s (e.g., a push request), where the OCS 108 influences the communication transfer service execution. Although the example is provided in the context of OCS 108, other types of CCN are also applicable.

[0075] As before, IMS subscriber Bob (UA-B) has 4 devices: a smart phone (UE-B1), a car phone (UE-B2), a PDA (UE-B3), and another smart phone (UE-B4). IMS subscriber Bob (UA-B) is served by AS 106 in a multi-device deployment.

[0076] Served user Bob’s devices UE-B1, UE-B2, and UE-B3 are IMS registered, as shown at 401.

[0077] AS 106 has learned identity and location information of all UEs of served user Bob, as shown at 402.

[0078] Step 1 : Bob (UE-B2) has an ongoing communication with Remote Party A (UA- A), as shown at 403. In this example, the ongoing communication is using 5G NR access.

[0079] Step 2: Bob wants to transfer the communication to another UE and sends a request to transfer to another of his UEs (e.g., a push request), to AS 106, as shown at 404.

[0080] Step 3: AS 106 sends a charging data request for a communication transfer request for Bob to OCS 108, as shown at 405. The request contains identity and location information of multiple UEs of Bob, as shown at 406.

[0081] Step 4: OCS 108 executes enhanced location-based policy service using the AS 106 provided identity and location information of Bob’s multiple UEs, as shown at 407. Based on this, communication transfer to UE-B4 (circuit switched access) and UE-B3 (WLAN access) is blocked due to 5G deployment restrictions of the operator, while communication transfer towards the remaining UE-B1 (LTE access) is allowed. OCS 108 acknowledges the AS 106 request by sending a successful charging data response, as shown at 408. In the response, the result value is set to blocked for UE-B3 and UE-B4 and set to allowed for UE-B1, as shown at 409.

[0082] Step 5: AS 106 distributes the communication to UE-B1, as shown at 410.

[0083] Step 6: Bob picks up the communication again using UE-B1 on LTE access, as shown at 411. [0084] Step 7: AS 106 sends a charging data request to OCS 108 with the answered UE (UE-B2), as shown at 412. The request contains identity and location information of answering UE-B1 (Bob’s primary UE) and the push-requesting UE (UE-B2), as shown at 413.

[0085] At this point, AS 106 contains the identity and location information for all of Bob’s UEs, as shown at 414. For example, the location information for UE 104a (UE-B1) may have been updated by the AS 106 based on information received when that UE answered the communication at 411.

[0086] Step 8: OCS 108 acknowledges the answering UE (UE-B1), its valid location, and allows the communication transfer, as shown at 415. OCS 108 sends a successful charging data response to AS 106, as shown at 416.

[0087] Step 9: Communication transfer setup continues, as shown at 417.

[0088] FIG. 5 illustrates a sequence diagram according to an embodiment. As shown, UE 102a, AS 106, UEs 104a-104d, HSS 110, and OCS 108 may communicate with each other. The numbered items 1-16 below correspond to the numbered items shown in FIG. 5. In the sequence shown in FIG. 5, AS 106 handles a communication transfer request from a nonparticipating UE of Bob’s requesting a transfer from a participating UE of Bob’s (e.g., a pull request), where the OCS 108 influences the communication transfer service execution. Although the example is provided in the context of OCS 108, other types of CCN are also applicable.

[0089] As before, IMS subscriber Bob (UA-B) has 4 devices: a smart phone (UE-B1), a car phone (UE-B2), a PDA (UE-B3), and another smart phone (UE-B4). IMS subscriber Bob (UA-B) is served by AS 106 in a multi-device deployment.

[0090] Served user Bob’s devices UE-B1, UE-B2, and UE-B3 are IMS registered, as shown at 501.

[0091] AS 106 has learned identity and location information of all UEs of served user Bob, as shown at 502.

[0092] Step 1 : Bob (UE-B4) has an ongoing communication with Remote Party A (UA- A), as shown at 503. In this example, the ongoing communication is using circuit switched access. [0093] Step 2: Bob wants to transfer the communication to another UE and sends a communication transfer request from a non-participating UE of Bob’s (UE-B2) requesting a transfer from a participating UE of Bob’s (UE-B4) to AS 106 to pull the ongoing communication from UE-B4 to UE-B2, as shown at 504. In this example, UE-B2 is on 5GNR access.

[0094] Step 3: AS 106 sends a charging data request for a communication transfer request for served user Bob having multiple UEs, as shown at 505. The request contains identity and location information of Bob’s multiple UEs, as shown at 506.

[0095] Step 4: OCS 108 executes enhanced location-based policy service on AS 106 provided identity and location information of Bob’s multiple UEs, as shown at 507. As a result, communication transfer to UE-B2 (on 5G access) from UE-B4 (on circuit switched access) is not allowed due to an operator specific 5G deployment restriction. OCS 108 acknowledges the AS 106 request by sending an unsuccessful charging data response, as shown at 508.

[0096] Step 5: AS 106 acknowledges the communication transfer request from Bob’s car phone (UE-B2) by sending an unsuccessful (blocked) response, as shown at 509.

[0097] At this point, AS 106 contains identity and location information for all of Bob’s UEs, as shown at 510. The communication remains on UE-B4 and continues, as shown at 510.

[0098] If the result had been different (i.e., if the UE requesting transfer (UE-B2) had been allowed instead of blocked), then the charging data response would indicate that and the transfer would proceed.

[0099] FIG. 6 illustrates a sequence diagram according to an embodiment. As shown, UE 102a, AS 106, UEs 104a-104d, HSS 110, OCS 108, and ECTC Application 112 may communicate with each other. The numbered items 1-12 below correspond to the numbered items shown in FIG. 6. In the sequence shown in FIG. 6, AS 106 handles a terminating communication request, where the ECTC Application 112 influences the communication service execution. Although the example is provided in the context of OCS 108 and ECTC Application 112, other types of CCN are also applicable. [0100] As before, IMS subscriber Bob (UA-B) has 4 devices: a smart phone (UE-B1), a car phone (UE-B2), a PDA (UE-B3), and another smart phone (UE-B4). IMS subscriber Bob (UA-B) is served by AS 106 in a multi-device deployment.

[0101] Served user Bob’s devices UE-B1, UE-B2, and UE-B3 are IMS registered, as shown at 601.

[0102] AS 106 has learned identity and location information of most of the UEs of served user Bob (specifically, UE-B1, UE-B2, and UE-B3), as shown at 602.

[0103] Step 1 : AS 106 of served user Bob (UA-B) receives a termination communication request from caller UA-A, as shown at 603.

[0104] Step 2: AS 106 does not have location information of UE-B4 and so fetches it from HSS 110, as shown at 604.

[0105] Step 3: HSS 110 acknowledges the AS 106 request with by sending the circuit switched access location of UE-B4, as shown at 605.

[0106] Step 4: AS 106 sends a charging data request for communication setup request for Bob, as shown at 606. The request contains identity and location information of multiple UEs of Bob, as shown at 607.

[0107] Step 5: OCS 108 executes enhanced location-based policy service on AS 106 provided identity and location information of Bob’s multiple UEs, as shown at 608. As a result, communication to UE-B4 (on circuit switched access) is blocked (e.g., due to an operator specific regulatory feature for UEs on circuit switched access), while communication towards the rest of the UEs is allowed. OCS 108 acknowledges the AS 106 request by sending a successful charging data response, as shown at 609. The response includes a result value set to blocked for UE-B4 and set to allowed for the rest of the UEs, as shown at 610.

[0108] Step 6 : AS 106 sends a query request to ECTC Application 112, as shown at 611. The request contains Caller UA-A details and details of allowed UEs of called subscriber UA-B from step 5, as shown at 612.

[0109] Step 7: ECTC Application 112 classifies caller UA-A as a telemarketer caller, e.g. based on analytic functions using crowd-sourced information collected from subscribers as well as from the IMS network. For example, by using general communication events of the network, traffic patterns of suspected nuisance callers can be identified by analytic functions. ECTC Application 112 acknowledges the AS 106 request by sending a response, as shown at 613. The response contains call treatment action: allowed, caller category: telemarketer, and allow call to only the Primary UE (UE-B1) of the subscriber UA-B, because the caller is not trust worthy. Other policies could also be used; for example, UA-B may in some embodiments select certain UEs associated with it that should receive telemarketer calls, or may elect not to receive such calls with any UE.

[0110] Step 8 : AS 106 distributes the communication to allowed UE (UE-B1), as shown at 614.

[0111] Step 9: Bob answers the communication using UE-B1, as shown at 615.

[0112] Step 10: AS 106 sends a charging data request to OCS 108, as shown at 616. The request contains identity and location information of the answering UE (UE-B1) of Bob which is a primary device of the subscriber in this case also, as shown at 617.

[0113] At this point, AS 106 contains identity and location information for all of Bob’s UEs, as shown at 618.

[0114] Step 11 : OCS 108 acknowledges the answering UE (UE-B1), its valid location, and allows the communication setup, as shown at 619. OCS 108 sends a successful charging data response, as shown at 620.

[0115] Step 12: Communication setup continues, as shown at 621.

[0116] FIG. 7 illustrates a sequence diagram according to an embodiment. As shown, UE 102a, AS 106, UEs 104a-104d, HSS 110, and ECC 114 may communicate with each other. The numbered items 1-13 below correspond to the numbered items shown in FIG. 7. In the sequence shown in FIG. 7, AS 106 handles a terminating communication request, where the ECC 114 influences the communication service execution. Although the example is provided in the context of ECC 114, other types of CCN are also applicable. [0117] As before, IMS subscriber Bob (UA-B) has 4 devices: a smart phone (UE-B1), a car phone (UE-B2), a PDA (UE-B3), and another smart phone (UE-B4). IMS subscriber Bob (UA-B) is served by AS 106 in a multi-device deployment.

[0118] Served user Bob’s devices UE-B1, UE-B2, and UE-B3 are IMS registered, as shown at 701.

[0119] AS 106 has learned identity and location information of most of the UEs of served user Bob (specifically, UE-B1, UE-B2, and UE-B3), as shown at 702.

[0120] Step 1 : AS 106 of served user Bob (UA-B) receives a termination communication request from Caller UA-A, as shown at 703.

[0121] Step 2: AS 106 does not have location information of UE-B4 and so it fetches it from HSS 110, as shown at 704.

[0122] Step 3: HSS 110 acknowledges the AS 106 request including the circuit switched access location of UE-B4 in its response, as shown at 705.

[0123] Step 4: AS 106 sends a REST Call Direction request to ECC 114 for subscriber Bob, as shown at 706. The request contains additional information with identity and location information of multiple UEs of Bob, as shown at 707.

[0124] Step 5: ECC 114 executes enhanced location-based policy service using the identity and location information of Bob’s multiple UEs provided by AS 106, as shown at 708. As a result, communication to UE-B3 (WiFi access) is blocked (e.g., due to an operator specific regulatory feature for UEs on WiFi access), while communication towards the other UEs is allowed.

[0125] Step 6: ECC 114 acknowledges the AS 106 request by sending a successful response, as shown at 709. The response includes instructions to (i) continue the communication setup for subscriber Bob, (ii) play an announcement to calling party UA-A, and (iii) additional information indicating to block communication for UE-B3 and allow communication for the other UEs of Bob, as shown at 710.

[0126] Step 7: Play announcement to caller UA-A, as shown at 711. [0127] Step 8 - Step 10: AS 106 distributes the communication to allowed UEs, as shown at 712 - 714.

[0128] Step 11 : Bob answers the communication from UE-B2, as shown at 715.

[0129] Step 12: AS 106 cancels communication towards UE-B1 and UE-B4, as shown at

716.

[0130] Stepl3: Communication setup continues between UA-A and UE-B2, as shown at

717.

[0131] Additionally, or alternatively, embodiments may work in a distributed manner across several nodes, because proposed reporting of identity and location information of multiple UEs of a subscriber to a CCN is centralized in AS 106.

[0132] FIG. 8 is a flowchart illustrating a process 800, according to an embodiment, performed by an application server (106) in communication with a communication controller node (108, 112, 114). Process 800 may begin in step s802.

[0133] Step s802 comprises sending, by the application server (106), a first control data request toward the communication controller node (108, 112, 114). The first control data request is for a call-related service involving a first user agent (102) and a second user agent (104). The first control data request comprises identity information and location information for a plurality of user equipments (UEs) (104a-104d) associated with the second user agent (104).

[0134] Step s804 comprises receiving, by the application server (106), a first control data response comprising result information for each of the plurality of UEs (104a-104d) associated with the second user agent (104) included in the first control data request.

[0135] Step s806 comprises processing the call-related service based on the first control data response.

[0136] In some embodiments, the application server (106) comprises an IP Multimedia Subsystem (IMS) Telephony Application Server (TAS). In some embodiments, the communication controller node (108, 112, 114) comprises one of an online charging system (108), an External Call Control (ECC) Application (114), an External Caller Treatment and Category (ECTC) Application (112). In some embodiments, the communication controller node (108, 112, 114) comprise an online charging system (108) and the first control data request comprises a charging data request. In some embodiments, the identity information for the plurality of UEs (104a-104d) associated with the second user agent (104) comprises, for each UE of the plurality of UEs (104a-104d), a distinct UE identifier associated with the UE. In some embodiments, the distinct UE identifier comprises an Internet Protocol (IP) Multimedia Private Identity (IMPI). In some embodiments, the identity information for the plurality of UEs (104a- 104d) associated with the second user agent (104) further comprises one or more of (i) a UE role, (ii) source information related to the identity information, and (iii) a UE type, associated with each of the plurality of UEs (104a-104d).

[0137] In some embodiments, the location information for the plurality of UEs (104a- 104d) associated with the second user agent (104) comprises one or more of (i) an access network information (ANI) and (ii) a geographical location. In some embodiments, the location information further comprises one or more of (i) source information related to the location information and (ii) an age of the location information indicating when the location information was provided or verified. In some embodiments, the method further includes collecting the identity information and location information for the plurality of UEs (104a-104d) associated with the second user agent (104). In some embodiments, collecting the identity information and location information for the plurality of UEs (104a-104d) associated with the second user agent (104) comprises one or more of (i) receiving the identity information and location information from one or more of the plurality of UEs; and (ii) requesting the identity information and location information from a network node. In some embodiments, the network node comprises a Home Subscriber Server (HSS) (110).

[0138] In some embodiments, the call-related service involving the first user agent (102) and the second user agent (104) comprises a communication setup request initiated by the first user agent (102). The method further includes determining, by the application server (106), a subset of allowed UEs of the plurality of UEs (104a-104d) associated with the second user agent (104) based on the result information in the first control data response. The method further includes sending, by the application server (106), a communication setup request message toward each of the allowed UEs in the subset of allowed UEs. The method further includes receiving, by the application server (106), an answer from an answering UE in the subset of allowed UEs. The method further includes canceling, by the application server (106), communication to each of the non-answering UEs in the subset of allowed UEs. In some embodiments, the method further includes sending, by the application server (106), a second control data request toward the communication controller node (108, 112, 114). The second control data request comprises identity information and location information of both the answering UE and a primary UE associated with the second user agent (104). The method further includes receiving, by the application server (106), a second control data response.

[0139] In some embodiments, the call-related service involving the first user agent (102) and the second user agent (104) comprises a communication transfer request from a participating UE of the second user agent (104) requesting a transfer to other UEs of the second user agent (104). The method further includes determining, by the application server (106), a subset of allowed UEs of the plurality of UEs (104a-104d) associated with the second user agent (104) based on the result information in the first control data response. The method further includes sending, by the application server (106), a communication transfer message toward each of the allowed UEs in the subset of allowed UEs. The method further includes receiving, by the application server (106), an answer from an answering UE in the subset of allowed UEs. The method further includes canceling, by the application server (106), communication to each of the non-answering UEs in the subset of allowed UEs. In some embodiments, the method further includes sending, by the application server (106), a second control data request toward the communication controller node (108, 112, 114). The second control data request comprises identity information and location information of the answering UE and the UE that initiated the communication transfer request. The method further includes receiving, by the application server (106), a second control data response.

[0140] In some embodiments, the call-related service involving the first user agent (102) and the second user agent (104) comprises a communication transfer request from a nonparticipating UE of the second user agent (104) requesting a transfer from a participating UE of the second user agent (104). The method further includes determining, by the application server (106), whether the requesting UE is allowed to be transferred the pending communication based on the result information in the first control data response. The method further includes, if it is determined that the requesting UE is allowed to be transferred the communication, (i) sending, by the application server (106), a communication transfer message toward the participating UE; and otherwise (ii) sending, by the application server (106), a failure message toward the requesting UE.

[0141] In some embodiments, the communication controller node comprises an External Caller Treatment and Category (ECTC) Application (112), and the result information for each of the plurality of UEs (104a-104d) is based on a trustworthiness determination about the first user agent (102).

[0142] FIG. 9 is a flowchart illustrating a process 900, according to an embodiment, performed by a communication controller node (108, 112, 114) in communication with an application server (106). Process 900 may begin in step s902.

[0143] Step s902 comprises receiving, by the communication controller node (108, 112, 114), a first control data request from the application server (106). The first control data request is for a call-related service involving a first user agent (102) and a second user agent (104). The first control data request comprises identity information and location information for a plurality of user equipments (UEs) (104a-104d) associated with the second user agent (104).

[0144] Step s904 comprises determining result information for each of the plurality of UEs (104a-104d) associated with the second user agent (104) included in the first control data request based on the identity information and location information for the plurality of UEs (104a- 104d). Such result information indicates whether communication to a particular UE is allowed.

[0145] Step s906 comprises sending, by the communication controller node (108, 112, 114), a first control data response toward the application server (106), wherein the first control data response comprises the result information for each of the plurality of UEs (104a-104d) associated with the second user agent (104) included in the first control data request.

[0146] In some embodiments, the application server (106) comprises an IP Multimedia Subsystem (IMS) Telephony Application Server (TAS). In some embodiments, the communication controller node (108, 112, 114) comprises one of an online charging system (108), an External Call Control (ECC) Application (114), an External Caller Treatment and Category (ECTC) Application (112). In some embodiments, the communication controller node (108, 112, 114) comprise an online charging system (108) and the first control data request comprises a charging data request. In some embodiments, the communication controller node (108, 112, 114) comprise an External Caller Treatment and Category (ECTC) Application (112) and wherein the result information for each of the plurality of UEs (104a-104d) is based on a trustworthiness determination about the first user agent (102).

[0147] In some embodiments, the identity information for the plurality of UEs (104a- 104d) associated with the second user agent (104) comprises, for each UE of the plurality of UEs (104a-104d), a distinct UE identifier associated with the UE. In some embodiments, the distinct UE identifier comprises an Internet Protocol (IP) Multimedia Private Identity (IMPI). In some embodiments, the identity information for the plurality of UEs (104a-104d) associated with the second user agent (104) further comprises one or more of (i) a UE role, (ii) source information related to the identity information, and (iii) a UE type, associated with each of the plurality of UEs (104a-104d). In some embodiments, the location information for the plurality of UEs (104a-104d) associated with the second user agent (104) comprises one or more of (i) an access network information (ANI) and (ii) a geographical location. In some embodiments, the location information further comprises one or more of: (i) source information related to the location information and (ii) an age of the location information indicating when the location information was provided or verified.

[0148] In some embodiments, the call-related service involving the first user agent (102) and the second user agent (104) comprises a communication setup request initiated by the first user agent (102). In some embodiments, the call-related service involving the first user agent (102) and the second user agent (104) comprises a communication transfer request from a participating UE of the second user agent (104) requesting a transfer to other UEs of the second user agent (104). In some embodiments, the call-related service involving the first user agent (102) and the second user agent (104) comprises a communication transfer request from a nonparticipating UE of the second user agent (104) requesting a transfer from a participating UE of the second user agent (104).

[0149] In some embodiments, determining result information for each of the plurality of UEs (104a-104d) is further based on operator-specific deployment policies. [0150] FIG. 10 is a block diagram of apparatus 1000 (e.g., AS 106, a CCN such as OCS 108, ECTC Application 112, ECC Application 114), according to some embodiments, for performing the methods disclosed herein. As shown in FIG. 10, apparatus 1000 may comprise: processing circuitry (PC) 1002, which may include one or more processors (P) 1055 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus 1000 may be a distributed computing apparatus); at least one network interface 1048 comprising a transmitter (Tx) 1045 and a receiver (Rx) 1047 for enabling apparatus 1000 to transmit data to and receive data from other nodes connected to a network 1010 (e.g., an Internet Protocol (IP) network) to which network interface 1048 is connected (directly or indirectly) (e.g., network interface 1048 may be wirelessly connected to the network 1010, in which case network interface 1048 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 1008, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. Interface 1060 may connect PC 1002 and storage unit 1008, interface 1062 may connect PC 1002 and network interface 1048, and interface 1064 may connect network interface 1048 and network 1010. In embodiments where PC 1002 includes a programmable processor, a computer program product (CPP) 1041 may be provided. CPP 1041 includes a computer readable medium (CRM) 1042 storing a computer program (CP) 1043 comprising computer readable instructions (CRI) 1044. CRM 1042 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 1044 of computer program 1043 is configured such that when executed by PC 1002, the CRI causes apparatus 1000 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 1000 may be configured to perform steps described herein without the need for code. That is, for example, PC 1002 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0151] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above described exemplary embodiments. Moreover, any combination of the above-described embodiments in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context. [0152] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.