Patent Publication Number: US-2022232049-A1

Title: Network node, ims node and methods in a communications network

Description:
TECHNICAL FIELD 
     Embodiments herein relate to a network node, an IMS node and methods therein. In particular, they relate to handling an outgoing media call of a user associated with multiple personas in a communications network. 
     BACKGROUND 
     In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or user equipment (UE), communicate via a Local Area Network such as a WiFi network or a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in 5th Generation (5G). A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node. The radio network node communicates to the wireless device in DownLink (DL) and from the wireless device in UpLink (UL). 
     Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (5G) network also referred to as 5G New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs used in 3rd Generation (3G) networks. In general, in E-UTRAN/LTE the functions of a 3G RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE, and the core network. As such, the RAN of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E-UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface. 
     Multi-antenna techniques can significantly increase the data rates and reliability of a wireless communication system. The performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. Such systems and/or related techniques are commonly referred to as MIMO. 
     In addition to faster peak Internet connection speeds, 5G planning aims at higher capacity than current 4G, allowing higher number of mobile broadband users per area unit, and allowing consumption of higher or unlimited data quantities in gigabyte per month and user. This would make it feasible for a large portion of the population to stream high-definition media many hours per day with their mobile devices, when out of reach of Wi-Fi hotspots. 5G research and development also aims at improved support of machine to machine communication, also known as the Internet of things, aiming at lower cost, lower battery consumption and lower latency than 4G equipment. 
     Over-The-Top (OTT) services have been introduced allowing a third party telecommunications service provider to provide services that are delivered across an Internet Protocol (IP) network. The IP network may e.g. be a public internet or cloud services delivered via a third party access network, as opposed to a carrier&#39;s own access network. OTT may refer to a variety of services including communications, such as e.g. voice and/or messaging, content, such as e.g. TV and/or music, and cloud-based offerings, such as e.g. computing and storage. 
     A further OTT service is a Digital Assistant (DA). The DA may perform tasks or services upon request from a user of a UE. The DA may be implemented in several ways. A first way is commonly referred to as an operator controlled DA. The operator controls the whole DA solution without the UE being impacted. A user of the UE may provide instructions, such as e.g. voice commands, to a core network node, such as e.g. an IP Multimedia Subsystem (IMS) node, of the operator. The voice command may e.g. be “Digital Assistant, I want a pizza”, “Digital Assistant, tell me how many devices are active right now”, “Digital Assistant, set-up a conference”, or “Digital Assistant, how much credit do I have?”. IMS is a general-purpose, open industry standard for voice and multimedia communications over packet-based IP networks. It is a core network technology, that may serve as a low-level foundation for technologies like Voice over LTE (VoLTE) Voice over IP (VoIP), Push-To-Talk (PTT), Push-To-View, Video Calling, and Video Sharing. 
     The core network node may detect a hot word, which may also be referred to as a key word, indicating that the user is providing instructions to the DA and may forward the instructions to a network node controlled by a third party service provider, the network node may e.g. comprise a DA platform. 
     The DA platform may e.g. be a bot of a company providing a certain service, such as e.g. a taxi service or a food delivery service. The instructions may be forwarded to the DA platform using e.g. a Session Initiation Protocol/Real-time Transport Protocol (SIP/RTP). The DA platform may comprise certain functionality, such as e.g. Speech to Text (Speech2Text), Identification of Intents &amp; Entities and Control &amp; Dispatch of Intents. 
     The DA platform may then forward the instructions to a further network node, which may e.g. be an Application Server (AS) node, which has access to the core network node via a service exposure Application Programming Interface (API). Thereby the DA may access the IMS node and perform services towards the core network node. 
     The DA platform is often required to pay a fee to the operator in order to be reachable by the operator&#39;s DA users. The user may also be required to pay fees to the operator and network provider for the usage of DA services. The operator may further be required to pay fees to the network provider for every transaction performed via the Service Exposure API. 
     A further way to implement the DA may be to provide the user with direct access to the network node controlled by the third party service provider comprising the DA platform. This may e.g. be done using a dedicated UE having access to the first network node. This way of implementing the DA is commonly referred to as an OTT-controlled DA. 
     One of the services that can be invoked may e.g. be a telephony services or bot, implemented by the operator. 
       FIG. 1  depicts an architecture for an OTT-controlled DA, i.e. a Telephony Bot Architecture. A user  10  of a DA comprising a smart speaker  20  may want to request actions, such as Call Bob, to an IMS network  30  e.g. comprising VoLTE, via an API Gateway  40 . If the request from the smart speaker  20  user  10  needs some IMS capabilities a OTT DA cloud  50  will use service exposure capabilities to access to it. For example, when the user  10  asks to include a 3rd person to the call or manipulate end user supplementary setting. 
     As mentioned above, A DA may handle communication via an API. In the context of an API, an intent is an abstract description of an operation to be performed. The text describing an intent and other aspects of API:s, when used herein, is written with the text font Courier New Italic. 
     In the case of an OTT-controlled DA, the DA may handle communication of the user via an Open Mobile Alliance (OMA) API. In section 5.1.3.1 of the Open Mobile Alliance™ specification, the Operation Make Call Session (MakeCallSession) in the “OMA API Call Control and Configuration”, an API may be invoked in order to set-up a call with a user or with a list of users. A Call Participants (CallParticipants) parameter comprises addresses of the participants involved in the call. 
     When an application invokes this OMA API, the network should setup a call among all the specified participants. 
     SUMMARY 
     As a part of developing embodiments herein the inventors identified a problem which first will be discussed. 
     As mentioned above, voice driven and/or hands-free use cases are increasing in popularity. Typically, if a user wishes to make an outgoing call, it is done from one of multiple personas belonging to that user. A persona when used herein refers to a persona in the IMS domain which may be a phone number associated with a user&#39;s role in life. For example, a user may have one phone number for private use and another one for business purposes. The user may have personas such as e.g. work, family, private, guest etc., that the user may use to perform the call. 
     The wording multiple personas, or multi-persona, when used herein means at least two personas. 
     Calling as a specific persona is generally triggered by the user directly on a UE. However, the user may instead wish to use voice to control the UE, such as with a DA. The user may e.g. be able to use a specific persona by saying the name of the persona he/she wants to use for the call, such as e.g. saying “Digital assistant, call as work”. In order for such a scenario to work, the DA application needs to invoke an appropriate logic from the IMS network. 
     A logic when used herein means a function that maps an indicated persona to an IMS user ID, i.e. couples an indicated persona to an IMS user ID, such as e.g. a telephone number. It requests the call to be set up to the IMS network. The appropriate logic comprises the persona of the device the call is originated from. 
     Such a logic flow thus requires the network to expose the logic and execute it, which is not possible in prior art solutions. The OMA standard list of APIs, e.g., does not provide an operation to expose this kind of action. The API MakeCallSession, mentioned above, does not include any parameter with an identifier for the persona from which the call is to be made. 
     An object of embodiments herein is therefore to improve the performance of a communications network comprising multi-persona users using DAs. 
     According to an aspect of embodiments herein, the object is achieved by a method performed by a network node, for handling an outgoing call from a first user in a communications network. The network node receives a request for the outgoing call to be set up via a first persona out of multiple personas associated with the first user, which request is obtained as a voice instruction from the first user via a Digital Assistant (DA) device. The voice instruction comprises a personalized name associated with the first persona of the first user. The network node further identifies among the multiple personas associated with the first user, an IMS user ID corresponding to the first persona based on the personalized name received in the voice instruction. The network node then sends, to an Internet Protocol Multimedia Subsystem (IMS) node in the communications network, the identified IMS user ID, and a request to initiate the outgoing call via the first persona of the first user. 
     According to another aspect of embodiments herein, the object is achieved by a method performed by an IMS node, for handling an outgoing media call of a user associated with at least one first persona out of multiple personas in a communications network. The IMS node receives, from a network node, an IMS user ID corresponding to the first persona and a request to initiate the outgoing media call via the first persona of the first user. When initiating the outgoing media call via the first persona is supported, the IMS node terminates the outgoing media call via the first persona. On the other hand, when initiating the outgoing media call via the first persona is not supported, the IMS node sends a response to the network node. The response comprises a message that the media call cannot be terminated via the first persona. 
     According to a further aspect of embodiments herein, the object is achieved by a network node, configured to handle an outgoing call from a first user in a communications network. The network node is further configured to: 
     receive a request for the outgoing call to be set up via a first persona out of multiple personas associated with the first user, which request is adapted to be obtained as a voice instruction from the first user via a DA device, which voice instruction is adapted to comprise a personalized name associated with the first persona of the first user, 
     identify among the multiple personas associated with the first user, an IMS user ID corresponding to the first persona based on the personalized name received in the voice instruction, and 
     send to an Internet Protocol Multimedia Subsystem, IMS, node in the communications network, the identified IMS user ID, and a request to initiate the outgoing call via the first persona of the first user. 
     According to a yet further aspect of embodiments herein, the object is achieved by an IMS node configured to handle an outgoing media call of a user associated with at least one first persona out of multiple personas in a communications network, the IMS node being further configured to: 
     receive, from a network node, an IMS user ID corresponding to the first persona and a request to initiate the outgoing media call via the first persona of the first user, 
     when initiating the outgoing media call via the first persona is supported, terminate the outgoing media call via the first persona, and 
     when initiating the outgoing media call via the first persona is not supported, send a response to the network node, which response is adapted to comprise a message that the media call cannot be terminated via the first persona. 
     The performance of a communications network comprising multi-persona users using DAs may be improved according to the embodiments above, e.g. since the network node may identify an IMS user ID corresponding to the first persona, among the multiple personas associated with the first user, and the IMS node may initiate the outgoing media call via the first persona when the first persona is supported. 
     Another advantage of embodiments herein is that it makes it possible to implement cases with e.g. outgoing voice calls without the need for interacting with the actual calling device, but voice driven via a Digital Assistant 
     Furthermore, the multi-persona functionality offered by IMS may be triggered for other agents and not only from the UEs, making it easier for the end user to expose his/her identity (business, public, private etc.) during a multimedia call. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Examples of embodiments herein are described in more detail with reference to attached drawings in which: 
         FIG. 1  is a schematic block diagram illustrating prior art. 
         FIG. 2  is a schematic block diagram illustrating embodiments of a communications network. 
         FIG. 3  is a schematic overview depicting embodiments of a method in the communications network. 
         FIG. 4  is a flowchart depicting embodiments of a method in a network node. 
         FIG. 5  is a flowchart depicting embodiments of a method in an IMS node. 
         FIG. 6  is a schematic overview depicting embodiments of a method in the communications network. 
         FIG. 7   a  and  b  are a schematic block diagrams illustrating embodiments of a network node. 
         FIG. 8   a  and  b  are schematic block diagrams illustrating embodiments of an IMS node. 
         FIG. 9  schematically illustrates a telecommunications network connected via an intermediate network to a host computer. 
         FIG. 10  is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection. 
         FIGS. 11 to 14  are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments herein focus on a multi-persona calling scenario. In such a scenario, a user may have access to multiple personas on a single piece of User Equipment (UE). mobile device so that they can easily balance business and personal communications. 
     Furthermore, some embodiments herein focus on a scenario with a user using voice and triggering a Digital Assistant via the service exposure layer of the IMS network. 
     An advantage of embodiments herein is that an outgoing call initiation from a DA device such as a smartspeaker or from a DA smartapp using voice control, e.g. in a multi-persona scenario, is made possible. 
     In prior art solutions, calling as a specific persona may only be triggered by the user directly on a UE, and not through voice control via e.g. a DA. As mentioned above, when the voice control is employed, such as e.g. using a DA, the logic flow requires the network to expose an appropriate logic and execute it. This exposure and the associated logic is made available through embodiments herein. 
     In some embodiments herein a solution is provided that comprises exposing the information about multi-persona in the existing IMS APIs. In some embodiments herein a solution is provided that comprises exposing the information about multi-persona in one or more new IMS API. This would allow the following use case example to be implemented: A user says to a digital assistant “Call as work”. A network node, such as an application server node, then requests that action to the IMS network via the proposed API. The IMS network subsequently continues the logic, i.e. outgoing call as the indicated persona. 
     Example embodiments herein may be based on an IMS network exposing an action to initiate a call from a specific persona. 
     Embodiments herein makes it possible to request a Digital Assistant to specify a persona when making a call. Furthermore, embodiments herein e.g. provide a mechanism such as an API to trigger that action in IMS network. 
       FIG. 2  is a schematic overview depicting a wireless communications network  100  wherein embodiments herein may be implemented. The wireless communications network  100  comprises one or more RANs  104  and one or more CNs  106 . The wireless communications network  100  may use 5G NR but may further use a number of other different technologies, such as, (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein may also be applicable to all legacy systems where IMS is the core. 
     Network nodes operate in the wireless communications network  100 , such as a radio network node  110  providing radio coverage. 
     The radio network node  110  provides radio coverage over a geographical area by means of antenna beams. The geographical area may be referred to as a cell, a service area, beam or a group of beams. The radio network node  110  may be a transmission and reception point e.g. a radio access network node such as a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), an NR Node B (gNB), a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point, a Wireless Local Area Network (WLAN) access point, an Access Point Station (AP STA), an access controller, a UE acting as an access point or a peer in a Device to Device (D2D) communication, or any other network unit capable of communicating with a UE within the cell served by the radio network node  110  depending e.g. on the radio access technology and terminology used. 
     UEs such as a UEs  121 ,  122  and  123  operate in the wireless communication network  100 . The UEs  121 ,  122 ,  123  may e.g. be a mobile station, a non-access point (non-AP) STA, a STA, a user equipment and/or a wireless terminals, an NB-IoT device, an eMTC device and a CAT-M device, a WiFi device, an LTE device and an NR device communicate via one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN). It should be understood by those skilled in the art that “UE” is a non-limiting term which means any terminal, wireless communication terminal, wireless device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets, television units or even a small base station communicating within a cell. The UEs  121 ,  122  and  123  may be referred to as a first UE  121 , a second UE  122  and a third UE  123 . 
     The CN further comprises an IMS node  130 . The IMS node  130  may be connected to a network node  150 . The network node  150  may be represented by an Application Server (AS) node. The network node  150  may be located in a cloud  101  as depicted in  FIG. 2 , in the CN or in a third Party domain of the communications network  100 . The network node  150  may act as a gateway to a platform node  151 , such as a DA platform, located in a third Party domain of the communications network  100 . Furthermore the IMS node  130 , the network node  150  and the platform node  151  may be collocated nodes, stand-alone nodes or distributed nodes comprised in a cloud  101 ,  106 . 
     In some embodiments, the DA may comprise a DA device  125 , the platform node  151  and applications associated with the DA, which applications may e.g. be comprised in the DA device  125  and/or the platform node  151 . The DA device  125  may e.g. be a smart speaker, such as Smart Speaker  20  shown in  FIG. 1 . The platform node  151  may, as described above, be located in a third party domain and be represented by e.g. be an OTT DA Cloud  50  as depicted in  FIG. 1 . 
     It should be noted that although terminology from 3GPP LTE has been used in this disclosure to exemplify the embodiments herein, this should not be seen as limiting the scope of the embodiments herein to only the aforementioned system. Other wireless or wireline systems, including WCDMA, WiMax, UMB, GSM network, any 3GPP cellular network or any cellular network or system, may also benefit from exploiting the ideas covered within this disclosure. 
     In some embodiments herein, an existing API may be updated, or, as an alternative, a new API may be created. In an example embodiment, an OMA API MakeCallSession with parameters participants and persona may be defined. In such a new or updated API, the participants may be specified by means of a userId which may be the IMS publicId. The persona may be specified by means of a telephone number or Session Initiation Protocol (SIP) ID. The returned value may be the result of the operation, i.e. success or failure. 
     Embodiments herein provide a way to request a Digital Assistant to request a call to be initiated from a specific persona among a user&#39;s multiple persona e.g. by means of an API according to embodiments herein. 
     According to some embodiments herein, therefore, a creation of a new API or an update of the existing OMA API MakeCallSession is provided to include a persona, such as the SIP ID. This function may be performed by an application server, such as e.g. a Multimedia Telephony Application Server, MTAS, IMS node  130 . The MTAS IMS Node  130  would be suitable for exposing this function since it is the natural IMS node where the logic is to be placed, and it does not preclude other nodes for implementation. 
     Exposing the function may also be performed by any other IMS Application Server handling calls. 
     The methods will first be described from a helicopter perspective as a signalling diagram showing involved nodes, such as the DA device  125 , the network node  150  and the IMS node  130  with reference to  FIG. 3 . Thereafter embodiments of the methods as seen from the perspective of the network node  150  and the IMS node  130 , respectively, will be individually described, briefly, one by one with reference to  FIGS. 4 and 5 . 
     An example of a use case of embodiments herein is depicted in  FIG. 3  and will be explained by means of the following example scenario. The actions in  FIG. 3  are referred to in the text by their respective reference signs in parentheses, e.g. ( 301 ). 
     A user A is associated with multiple personas (Pn). The multiple personas may be e.g. work, family, friend, coach etc. 
     In the example use case, the user A wants to call another user, a user B, using a specific persona, such as a first persona P 1 . 
     To make a call to the user B via the first persona P 1 , the user A would provide a voice instruction to the DA device  125 . The user A may e.g. say “Digital assistant, call user B as P 1 ”. In the example scenario, the user A requests the digital assistant to set up an outgoing call to the user B via a specified persona and, thus, the DA device  125  receives ( 301 ) a voice instruction from the user A. 
     The request is thereafter sent ( 302 ) to the network node  150 . The request is sent in a message, e.g. comprising identifiers for the intended participants in the call, the user B in the example scenario, and the persona with which the call is to be initiated, i.e. the first persona P 1  in the example scenario. The identifier for the user B may be a personalized name configured by the user A, or an IMS Public User identity, IMPU, corresponding to the user B. The nature of the identifier depends on where in the system the mapping of personalized names to corresponding digital IDs, such as IMPUs, is performed. The identifier for the first persona P 1  may be a personalized name assigned to the persona P 1  by the user A, such as “work”. 
     According to embodiments herein, the network node  150 , having received the request with the included IDs, performs ( 303 ) a mapping. Mapping may e.g. mean that the network node  150 , knowing the personalized name assigned by the user, may e.g. check in a list to identify an ID corresponding to that particular personalized name. The result of the mapping is thus that an IMS user ID corresponding to the personalized name is identified, i.e. an IMS user ID corresponding to the personalized name “work” for the persona P 1  in the example scenario. The IMS user ID may e.g. be a telephone number or a Session Initiation Protocol, SIP, identity. for the persona P 1 . 
     Thereafter, according to embodiments herein, a request is sent ( 304 ) from the network node  150  to the IMS node  130  to initiate the outgoing call. 
     In some embodiments, the network node may further request the IMS node to perform a check. The check may involve verifying if initiating the outgoing call via the first persona P 1  of the first user A is supported by the IMS node. In the example scenario, the request would be to check if initiating the outgoing call via the first persona P 1  is supported. 
     In some embodiments herein, having received the request, the IMS node  130  performs the requested check ( 305 ). If the result of the check is that the outgoing call may be initiated via the first persona P 1 , the call may be terminated ( 306 ). In the example scenario, if the outgoing call may be initiated via the first persona P 1 I, the requested outgoing call may be successfully set up between the user A and the user B, via the first P 1  of the user, i.e. the “work” persona. A response may also be sent back to the network node  150  indicating that the operation was successful. 
     If, on the other hand, the result of the check is that the outgoing call may not be initiated via the first persona P 1 , the call cannot be terminated. A response may therefore be sent ( 307 ) back to the network node  150 . The response may comprise a message that the operation was not successful with the given parameters. In the example scenario, the message is sent that initiating the outgoing call via the first persona P 1  of the first user A is not supported by the IMS node  130 . 
     The network node  150  may then decide ( 308 ) how to proceed with the process of setting up the call. 
     In some embodiments herein, the network node  150  will send a response ( 309 ) to the DA device  125  indicating the result of the operation as requested. Furthermore, the message may include instructions for how to proceed with handling the requested media call, in accordance with what has been decided by the network node. In the example scenario the response may comprise instructing the DA device  125  to tell the user A that the persona P 1  was not accepted for the requested outgoing call. 
     There may be several reasons for why initiating an outgoing media call via a specific persona may not be supported. Such reasons may e.g. be if the user has configured the persona in such a way. A company may e.g. not allow a user to make outgoing calls from his/her business persona after office hours. 
     Having received the response from the network node, the DA device  125  may have been instructed to ask ( 310 ) the user A to provide new or additional instructions for how to handle the requested outgoing call. In the example scenario, the DA device  125  may offer the first user A to set up the outgoing media call via a second persona P 2  out of the multiple personas Pn of the first user A. The alternative persona may be referred to by the DA device  125  with the personalized name so that it is recognizable to the user A. Consequently, in order to enable this, a mapping between personalized names of the multiple personas Pn associated with user A may have been previously performed. 
     Alternatively, the DA device  125  may ask the user A to provide an alternative persona format for the requested outgoing call. 
     Additionally or optionally, the DA device  125  may just inform the first user A that the outgoing call cannot be set up via the first persona P 1  out of the multiple personas Pn. 
     Thereafter, the flow according to  FIG. 3  may be repeated until a successful operation has been performed and a media call may be terminated between the user A and the user B. 
     To enable the process shown in  FIG. 3 , the IMS node  130  may expose an API to network node  150 . As mentioned above, in some embodiments herein, the API MakeCallSession may be used with parameters participants, and persona. The participants may be specified by means of a userId which may be the IMS publicId the persona may be specified e.g. by means of an IMS identifier such as a telephone number or SIP identity representing the persona that the user wants to use in the call. 
     Using the example embodiment depicted in  FIG. 3  and explained above, an example use case for the above API may be explained as follows. 
     In the example embodiment, the OMA API MakeCallSession may be altered to fit the desired operation. A MakeCallSession request is to be made, which requires input parameters. These parameters may be expressed as participants and persona. 
     The Participants parameter may represent one or more users that should receive the outgoing call. In this example embodiment, there is only one participant—the user B. The user B may be identified with a userId, which for the purpose of MakeCallSession is the publicId which may be his/her allocated IMPU. The IMPU is a unique permanently allocated global identity assigned by the home network operator. 
     The persona parameter may be the persona that is intended to be used for the call. In this example embodiment, the persona is the persona P 1 . The persona may be identified using an IMS user ID, such as the telephone number or SIP identity associated with that persona. 
     In order to translate the personalized name for the persona, employed by the user, to an IMS user ID, the DA system may be configured so that there is a mapping between an ID for the persona, such as the IMS user ID, and the personalized name associated with that persona: The personalized name is used herein to indicate the name that is said by the user in the voice instruction to the DA device  125 . In the example embodiment, the personalized name for the requested first persona, P 1 , may e.g. be “work”. 
     Thus, in the example embodiment, the MakeCallSession would be given the parameters: 
     the IMPU corresponding to the user B, and 
     the IMS user ID corresponding to the persona P 1 , which the user A calls “work”. 
     In some embodiments, it may be possible that the operator has a mapping between the IMS user ID and the personalized name for a user&#39;s personas. The operator may for example have registered that a certain telephone number corresponds to the spoken word “work”. Furthermore, the user may use the IMS user ID for the persona instead of assigning a personalized name. 
     Example embodiments of, a method performed by the network node  150 , for handling an outgoing call from the first user A in a communications network  100  will now be described with reference to a flowchart depicted in  FIG. 4 . 
     The network node  150  may be represented by an application server node, such as e.g. a skill server or an agent server. 
     The method comprises the following actions, which actions may be taken in any suitable order. Actions that are optional are presented in dashed boxes in  FIG. 4 . 
     Action  401   
     In order to facilitate a mapping between personalized names for the multiple personas Pn and their corresponding IMS user IDs, the DA device  125  may first be configured by the user. 
     In an example scenario herein, the user A is associated with multiple personas, Pn. The configuration, which may be an automatic configuration phase, when exemplified with the scenario involving the user A may comprise the following:
         The user A sets up the DA device  125  to manage his/her multiple personas Pn.   The DA device  125  triggers, via the network node  150 , an application server, such as the MTAS, to start a set up phase.   The user A instructs the DA device  125  what personalized name he/she wants to allocate to a persona, such as “work”, “family”, “coach” etc.   A set-up completion may be performed.       

     When the set-up is completed, the DA device  125  is configured so that the personalized names employed by the user A are coupled with digital identifiers that may be employed by the various nodes in the communications network  100 . 
     In some embodiments, when a user is associated with multiple UEs, such as a phone, a TV and a tablet etc., the configuration may further include coupling personalized names for each out of the multiple devices with a digital identifier. These identifiers may then be employed by the various nodes in the communications network  100 , in a scenario when a user requests to set up a call using a specific UE. Furthermore, such a configuration may allow the identifiers to be employed by the various nodes in the communications network  100 , in a scenario when a user requests to set up a call via a specific persona and using a specific UE. 
     Action  402   
     The network node  150  receives a request for the outgoing call to be set up via a first persona P 1  out of multiple personas Pn associated with the first user A. The request is obtained as a voice instruction from the first user A via the DA device  125 . The voice instruction comprises a personalized name associated with the first persona P 1  of the first user A. 
     According to some embodiments, the request may further comprise a request for the outgoing media call to be set up from the first UE  121  out of the multiple UEs  121 ,  122 ,  123  associated with the first user A. The voice instruction may further comprise a personalized name associated with the first UE  121 . These embodiments will be further described in detail below. 
     This Action is related to Action  302  described above. 
     Action  403   
     After the network node  150  has received the request, it identifies among the multiple personas Pn associated with the first user A, an IMS user ID corresponding to the first persona P 1  based on the personalized name received in the voice instruction. 
     According to the embodiments where the user A is associated with multiple UEs  121 ,  122 ,  123 , the network node may further identify, among the multiple UEs  121 ,  122 ,  123 , the first UE  121  and its associated IMS identifier based on the personalized name received in the voice instruction. 
     This Action is related to Action  303  described above. 
     Action  404   
     The network node  150  then sends to the IMS node  130  in the communications network  100 , the identified IMS user ID, and a request to initiate the outgoing call via the first persona P 1  of the first user A. 
     According to some embodiments, the request to initiate the outgoing call via the first persona P 1  of the first user A further comprises a request to check if initiating the outgoing call via the first persona P 1  of the first user A is supported by the IMS node. 
     According to the embodiments where the user A is associated with multiple UEs  121 ,  122 ,  123 , the network node  150  may further send the identified IMS identifier of the first UE  121  and a request to whether or not the first UE  121  is registered in the IMS node  130  and supports media of the outgoing call. 
     This Action is related to Action  304  described above. 
     Action  405   
     According to some embodiments, when an indication from the IMS node  130  that the outgoing call cannot be initiated via the first persona P 1  of the first user A is received by the network node  150 , it may instruct the DA device  125  to offer the first user A to set up the outgoing media call via a second persona P 2  out of the multiple personas Pn of the first user A. 
     This Action is related to Action  309  described above. 
     Action  406   
     According to some embodiments, when an indication from the IMS node  130  that the outgoing call cannot be initiated via the first persona P 1  of the first user A is received by the network node  150 , it may instruct the DA device  125  to inform the first user A that the outgoing media call cannot be set up via the first persona P 1  out of the multiple personas Pn of the first user A. 
     This Action is related to Action  309  described above. 
     Example embodiments of a method performed by the IMS node  130 , for handling an outgoing media call of the user A associated with at least one first persona P 1  out of multiple personas Pn in a communications network  100  will now be described with reference to a flowchart depicted in  FIG. 5 . 
     The method comprises the following actions, which actions may be taken in any suitable order. Actions that are optional are presented in dashed boxes in  FIG. 5 . 
     Action  501   
     In order to facilitate handling of an upcoming outgoing media call, the IMS node  130  may expose an Application Program Interface, API, to the network node  150 . The API may comprise parameters associated with making a call session related to the upcoming outgoing call and requesting at least IMS user IDs for at least the first persona P 1  of the user A. 
     The wording to expose, when used herein, means to make accessible, such as e.g. to provide access to authorized clients to the network capabilities via an API. 
     The API parameters may e.g. be intended participants in the media call defined by corresponding IMS Public User identities, and the respective IMS user ID defining the first persona P 1 . 
     Action  502   
     For handling the outgoing media call of the user A, the IMS node  130  first receives, from the network node  150 , an IMS user ID corresponding to the first persona P 1  and a request to initiate the outgoing media call via the first persona P 1  of the first user A. 
     According to some embodiments, the network node may further receive, from the network node  150 , an IMS identifier corresponding to the first UE  121  among multiple UEs  121 ,  122  associated with the user A, and a request to whether or not the first UE  121  is registered in the IMS node  130  and supports media of the outgoing media call. 
     These embodiments will be further described in detail below. 
     This Action is related to Actions  304  and  305  described above. 
     Action  503   
     The IMS node  130  terminates the outgoing media call via the first persona P 1 , when initiating the outgoing media call via the first persona P 1  is supported. 
     According to the embodiments when the user A is associated with multiple UEs  121 ,  122 , the IMS node  130  may, when the first UE  121  is registered in the IMS node  130  and supports the media of the outgoing media call, terminate the outgoing call from the first UE  121  via the first persona P 1 . 
     This Action is related to Action  306  described above. 
     Action  504   
     When, on the other hand, an initiation of the outgoing media call via the first persona P 1  is not supported, the IMS node  130  sends a response to the network node  150 , which response comprises an indication that the media call cannot be terminated via the first persona P 1 . 
     According to the embodiments when the user A is associated with multiple UEs  121 ,  122  the network node may, when the first UE  121  is not registered in the IMS node  130  and/or the first UE  121  does not support the outgoing media call, send a response to the network node  150  that the media call cannot be terminated from the first UE  121  using the first persona P 1 . 
     This Action is related to Action  307  described above. 
     Embodiments herein such as mentioned above will now be further described and exemplified. The text below is applicable to and may be combined with any suitable embodiment described above. 
     A further example of an additional use case of embodiments herein is depicted in  FIG. 6  and will be explained by means of the following example scenario. 
     In the scenario depicted in  FIG. 6 , the user A wishes to set up a call with the user B, similarly to the example scenario depicted in the flowchart in  FIG. 3 . In  FIG. 6  however, in addition to being associated with multiple personas p 1 , P 2  etc., the user A is also associated with multiple UEs  121 ,  122 ,  123 . The UEs  121 ,  122 ,  123  may e.g. be a smartphone, a fixed telephone and a TV. Furthermore the user A may want to use various media formats for making calls, such as e.g. voice (audio) and video calls. The multiple UEs  121 ,  122 ,  123  may support different media formats. 
     In the example scenario, the user A wants to call the other user B from a specific UE out of the multiple UEs and using a specific persona out of the multiple personas. The user A may e.g. want to call the user B from the UE  121  using a first persona, P 1 . The user A may also request a specific media format to be used for the call. In the example scenario, the user A wishes to make a video call from the UE  121  using the first persona, P 1 . 
     To make a video call to the user B from the UE  121  using the first persona P 1 , user A would provide a voice instruction to the DA device  125 . The user A may e.g. say “Digital assistant, make a video call to user B from the UE  121  as persona P 1 ”. The DA device  125  would then convey the request to the network node  150 , which may be done via a platform node  151 . 
     The network node  150  may then perform a mapping in a similar fashion to what has been described in embodiments above. In this scenario however, the personalized name that user A employs for the UE  121  may also be mapped to an IMS identifier corresponding to that personalized name. Such an IMS identifier may e.g. be Universally Unique Identifier, UUID, for the UE  121 . 
     Furthermore, if a request is sent from the network node  150  to the IMS node  130  to perform a check, the check may additionally involve verifying if the requested IMS identifier is registered in the IMS node  130  and supports the outgoing media call. The outgoing media call may e.g. not be supported if the requested UE does not support the requested media format. In the example scenario, the UE 122  e.g. may not support video calls. 
     In the example scenario, the request would then be to check whether:
         The requested UE is registered in the IMS node  130  and supports video calls, and   initiating the outgoing call via the first persona P 1  of the first user A is supported by the IMS node.       

     Only if both checks generate a positive result may the outgoing call be terminated. This means that the call cannot be terminated from a registered UE if it does not support the requested media format, even if initiating the outgoing call via the first persona P 1  of the first user A is supported. In the example scenario, if the user request to make a video call from the UE  122 , the call may not be terminated since the UE  122  does not support setting up a video call to the user B. 
     Thus, in the example scenario, if initiating the outgoing call via the first persona P 1  of the first user A is supported by the IMS node, the call may be terminated as long as the UE  121  is registered in the IMS node  130  and supports video calls. In such a scenario, the video call may be set up from the user A, as the first persona P 1  using the first UE  121 , to the user B. 
     On the other hand, if the call could not be terminated, the network node  150  may then decide how to proceed with the process of setting up the call. This process is similar to the example scenario depicted  FIG. 3 , with adequate changes to accommodate the additional possibilities provided by the multiple UEs. The DA device  125  may e.g. ask the user A to select an alternative UE for the requested outgoing call. 
     It should be clear to those skilled in the art that many combinations of possibilities for the interaction between the DA device  125  and the user are available, and that the choices of actions to take following an unsuccessful operation to terminate a call are by no means limited to those exemplified. 
     Following an unsuccessful attempt to terminate a call from a specific device such as the first UE  121  using a specified persona, the flow of interaction described here and depicted in  FIG. 6  may be repeated until a successful operation has been performed and a media call may be terminated between the user A and the user B. 
     To perform the method actions above for handling an outgoing media call of a user A associated with at least one first persona P 1  out of multiple personas Pn in a communications network  100 , the network node  150  may comprise the arrangement depicted in  FIG. 7 a    and  FIG. 7   b.    
     The network node  150  may be adapted to be represented by an application server node. 
     The network node  150  may comprise an input and output interface  700  depicted in  FIG. 7 a   , configured to communicate e.g. with the IMS node  130 . The input and output interface  700  may comprise a wireless receiver not shown and a wireless transmitter not shown. 
     The network node  150  may be configured, e.g. by means of a configuring unit  720  in the network node  150  depicted in  FIG. 7 b   , to prompt a configuration of the DA device. 
     The network node  150  may further be configured to receive, e.g. by means of the receiving unit  730  in the network node  150 , a request for the outgoing call to be set up via a first persona P 1  out of multiple personas Pn associated with the first user A, which request is adapted to be obtained as a voice instruction from the first user A via a Digital Assistant, DA, device  125 , which voice instruction is adapted to comprise a personalized name associated with the first persona P 1  of the first user A. 
     The request obtained as a voice instruction from the first user A may be further adapted to comprise a request for the outgoing media call to be set up from a first User Equipment, UE,  121  out of multiple UEs  121 ,  122  associated with the first user A, and wherein the voice instruction is further adapted to comprise a personalized name associated with the first UE  121 . 
     The network node  150  may further be configured to identify, e.g. by means of the identifying unit  740  in the network node  150 , among the multiple personas Pn associated with the first user A, an IMS user ID corresponding to the first persona P 1  based on the personalized name received in the voice instruction. 
     The network node may further be configured to identify, e.g. by means of the identifying unit  740  in the network node  150 , among the multiple UEs  121 ,  122 , the first UE  121  and its associated IMS identifier based on the personalized name received in the voice instruction, The network node  150  may further be configured to send, e.g. by means of the sending unit  750  in the network node  150 , to an Internet Protocol Multimedia Subsystem, IMS, node  130  in the communications network  100 , the identified IMS user ID, and a request to initiate the outgoing call via the first persona P 1  of the first user A. 
     The network node may further be configured to send, e.g. by means of the sending unit  750  in the network node  150 , to the IMS node  130 , the identified IMS identifier of the first UE  121  and a request to whether or not the first UE  121  is registered in the IMS node  130  and supports media of the outgoing media call. 
     The network node  150  may further be configured to when receiving from the IMS node  130  an indication that the outgoing call cannot be initiated via the first persona P 1  of the first user A, instruct, e.g. by means of the instructing unit  730  in the network node  150 , the DA device  125  to offer the first user A to set up the outgoing media call via a second persona P 2  out of the multiple personas of the first user A. 
     In some embodiments herein, the request to initiate the outgoing call via the first persona P 1  of the first user A is further adapted to comprise a request to check if initiating the outgoing call via the first persona P 1  of the first user A is supported by the IMS node. 
     The network node  150  may further be configured to when receiving from the IMS node  130  an indication that the outgoing call cannot be initiated via the first persona P 1  of the first user A, instruct, e.g. by means of the instructing unit  730  in the network node  150 , the DA device  125  to inform the first user A that the outgoing media call cannot be set up via the first persona P 1  out of the multiple personas Pn of the first user A. 
     The embodiments herein may be implemented through a respective processor or one or more processors, such as a processor  715  of a processing circuitry in the network node  150  depicted in  FIG. 7 a   , together with a respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the network node  150 . One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the network node  150 . 
     The network node  150  may further comprise a memory  710  comprising one or more memory units to store data on. The memory comprises instructions executable by the processor  715 . The memory  710  is arranged to be used to store e.g. intents, instructions, configurations and applications to perform the methods herein when being executed in the network node  150 . 
     Those skilled in the art will also appreciate that the units in the radio network node  150  mentioned above may refer to a combination of analogue and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the network node  150  that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry ASIC, or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip SoC. 
     In some embodiments, a computer program  790  comprises instructions, which when executed by the respective at least one processor  715 , cause the at least one processor  715  of the network node  150  to perform the actions above. 
     In some embodiments, a carrier  795  comprises the computer program  790 , wherein the carrier  795  is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium. 
     To perform the method actions above for handling an outgoing media call of a user A associated with at least one first persona P 1  out of multiple personas Pn in a communications network  100 , the IMS node  130  may comprise the arrangement depicted in  FIG. 8 a    and  FIG. 8   b.    
     The IMS node  130  may comprise an input and output interface  800  depicted in  FIG. 8 a   , configured to communicate e.g. with the network node  150 . The input and output interface  700  may comprise a wireless receiver not shown and a wireless transmitter not shown. 
     The IMS node  130  may be configured to, e.g. by means of a exposing unit  820  in the IMS node  130 , expose to the network node  150 , an Application Program Interface, API, adapted to comprise parameters associated with making a call session related to the upcoming outgoing media call and adapted to request at least IMS user IDs for at least the first persona P 1  of the user A. 
     The API parameters may be adapted to comprise any one out of: intended participants in the media call defined by corresponding IMS Public User identities, and the respective IMS user ID defining the first persona P 1 . 
     The IMS node  130  is configured to, e.g. by means of a receiving unit  830  in the IMS node  130  depicted in  FIG. 8 b   , receive, from a network node  150 , an IMS user ID corresponding to the first persona P 1  and a request to initiate the outgoing media call via the first persona P 1  of the first user A. 
     The IMS node  130  may be further configured to, e.g. by means of the receiving unit  850  in the IMS node  130 , receive from the network node  150 , an IMS identifier corresponding to a first UE  121  among multiple UEs  121 ,  122  associated with the user A, and a request to whether or not the first UE  121  is registered in the IMS node  130  and supports media of the outgoing media call. 
     When initiating the outgoing media call via the first persona P 1  is supported, the IMS node  130  is further configured to, e.g. by means of a terminating unit  840  in the IMS node  130 , terminate the outgoing media call via the first persona P 1 . 
     When initiating the outgoing media call via the first persona P 1  is supported and the first UE  121  is registered in the IMS node  130  and supports the media of the outgoing media call, the IMS node  130  may be further configured to, e.g. by means of the terminating unit  840  in the IMS node  130 , terminate the outgoing media call from the first UE  121  via the first persona P 1 . 
     When initiating the outgoing media call via the first persona P 1  is not supported, the IMS node  130  is further configured to, e.g. by means of a sending unit  850  in the IMS node  130 , send a response to the network node  150 , which response is adapted to comprise a message that the media call cannot be terminated via the first persona P 1 . 
     When initiating the outgoing media call via the first persona P 1  of the first user A is not supported and/or the first UE  121  is not registered in the IMS node  130  and/or the first UE  121  does not support the outgoing media call, the IMS node  130  may be further configured to, e.g. by means of the sending unit  850  in the IMS node  130 , send a response to the network node  150 , which response is adapted to comprise a message that the media call cannot be terminated from the first UE  121  using the first persona P 1 . 
     The embodiments herein may be implemented through a respective processor or one or more processors, such as a processor  815  of a processing circuitry in the IMS node  130  depicted in  FIG. 8 a   , together with a respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the IMS node  130 . One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the IMS node  130 . 
     The IMS node  130  may further comprise a memory  810  comprising one or more memory units to store data on. The memory comprises instructions executable by the processor  815 . The memory  810  is arranged to be used to store e.g. intents, instructions, configurations and applications to perform the methods herein when being executed in the IMS node  130 . 
     Those skilled in the art will also appreciate that the units in the IMS node  130  mentioned above may refer to a combination of analogue and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in IMS node  130  that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC). 
     In some embodiments, a computer program  890  comprises instructions, which when executed by the at least one processor  815 , cause the at least one processor  815  of IMS node  130  to perform the actions above. 
     In some embodiments, a carrier  895  comprises the computer program  890 , wherein the carrier  895  is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium. 
     Further Extensions and Variations 
     With reference to  FIG. 9 , in accordance with an embodiment, a communication system includes a telecommunication network  3210  such as the wireless communications network  100 , e.g. a NR network, such as a 3GPP-type cellular network, which comprises an access network  3211 , such as a radio access network, and a core network  3214 . The access network  3211  comprises a plurality of base stations  3212   a ,  3212   b ,  3212   c , such as the radio network node  110 , access nodes, AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area  3213   a ,  3213   b ,  3213   c . Each base station  3212   a ,  3212   b ,  3212   c  is connectable to the core network  3214  over a wired or wireless connection  3215 . A first user equipment (UE) e.g. the wireless devices  120  such as a Non-AP STA  3291  located in coverage area  3213   c  is configured to wirelessly connect to, or be paged by, the corresponding base station  3212   c . A second UE  3292  e.g. the first or second radio node  110 ,  120  or such as a Non-AP STA in coverage area  3213   a  is wirelessly connectable to the corresponding base station  3212   a . While a plurality of UEs  3291 ,  3292  are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station  3212 . 
     The telecommunication network  3210  is itself connected to a host computer  3230 , which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer  3230  may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections  3221 ,  3222  between the telecommunication network  3210  and the host computer  3230  may extend directly from the core network  3214  to the host computer  3230  or may go via an optional intermediate network  3220 . The intermediate network  3220  may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network  3220 , if any, may be a backbone network or the Internet; in particular, the intermediate network  3220  may comprise two or more sub-networks (not shown). 
     The communication system of  FIG. 9  as a whole enables connectivity between one of the connected UEs  3291 ,  3292  and the host computer  3230 . The connectivity may be described as an over-the-top (OTT) connection  3250 . The host computer  3230  and the connected UEs  3291 ,  3292  are configured to communicate data and/or signaling via the OTT connection  3250 , using the access network  3211 , the core network  3214 , any intermediate network  3220  and possible further infrastructure (not shown) as intermediaries. The OTT connection  3250  may be transparent in the sense that the participating communication devices through which the OTT connection  3250  passes are unaware of routing of uplink and downlink communications. For example, a base station  3212  may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer  3230  to be forwarded (e.g., handed over) to a connected UE  3291 . Similarly, the base station  3212  need not be aware of the future routing of an outgoing uplink communication originating from the UE  3291  towards the host computer  3230 . 
     Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to  FIG. 10 . In a communication system  3300 , a host computer  3310  comprises hardware  3315  including a communication interface  3316  configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system  3300 . The host computer  3310  further comprises processing circuitry  3318 , which may have storage and/or processing capabilities. In particular, the processing circuitry  3318  may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer  3310  further comprises software  3311 , which is stored in or accessible by the host computer  3310  and executable by the processing circuitry  3318 . The software  3311  includes a host application  3312 . The host application  3312  may be operable to provide a service to a remote user, such as a UE  3330  connecting via an OTT connection  3350  terminating at the UE  3330  and the host computer  3310 . In providing the service to the remote user, the host application  3312  may provide user data which is transmitted using the OTT connection  3350 . 
     The communication system  3300  further includes a base station  3320  provided in a telecommunication system and comprising hardware  3325  enabling it to communicate with the host computer  3310  and with the UE  3330 . The hardware  3325  may include a communication interface  3326  for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system  3300 , as well as a radio interface  3327  for setting up and maintaining at least a wireless connection  3370  with a UE  3330  located in a coverage area (not shown in  FIG. 10 ) served by the base station  3320 . The communication interface  3326  may be configured to facilitate a connection  3360  to the host computer  3310 . The connection  3360  may be direct or it may pass through a core network (not shown in  FIG. 10 ) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware  3325  of the base station  3320  further includes processing circuitry  3328 , which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station  3320  further has software  3321  stored internally or accessible via an external connection. 
     The communication system  3300  further includes the UE  3330  already referred to. Its hardware  3335  may include a radio interface  3337  configured to set up and maintain a wireless connection  3370  with a base station serving a coverage area in which the UE  3330  is currently located. The hardware  3335  of the UE  3330  further includes processing circuitry  3338 , which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE  3330  further comprises software  3331 , which is stored in or accessible by the UE  3330  and executable by the processing circuitry  3338 . The software  3331  includes a client application  3332 . The client application  3332  may be operable to provide a service to a human or non-human user via the UE  3330 , with the support of the host computer  3310 . In the host computer  3310 , an executing host application  3312  may communicate with the executing client application  3332  via the OTT connection  3350  terminating at the UE  3330  and the host computer  3310 . In providing the service to the user, the client application  3332  may receive request data from the host application  3312  and provide user data in response to the request data. The OTT connection  3350  may transfer both the request data and the user data. The client application  3332  may interact with the user to generate the user data that it provides. 
     It is noted that the host computer  3310 , base station  3320  and UE  3330  illustrated in  FIG. 10  may be identical to the host computer  3230 , one of the base stations  3212   a ,  3212   b ,  3212   c  and one of the UEs  3291 ,  3292  of  FIG. 9 , respectively. This is to say, the inner workings of these entities may be as shown in  FIG. 10  and independently, the surrounding network topology may be that of  FIG. 9 . 
     In  FIG. 10 , the OTT connection  3350  has been drawn abstractly to illustrate the communication between the host computer  3310  and the use equipment  3330  via the base station  3320 , without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE  3330  or from the service provider operating the host computer  3310 , or both. While the OTT connection  3350  is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). 
     The wireless connection  3370  between the UE  3330  and the base station  3320  is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE  3330  using the OTT connection  3350 , in which the wireless connection  3370  forms the last segment. More precisely, the teachings of these embodiments may improve the data rate, latency, power consumption and thereby provide benefits such as user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime. 
     A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection  3350  between the host computer  3310  and UE  3330 , in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection  3350  may be implemented in the software  3311  of the host computer  3310  or in the software  3331  of the UE  3330 , or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection  3350  passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software  3311 ,  3331  may compute or estimate the monitored quantities. The reconfiguring of the OTT connection  3350  may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station  3320 , and it may be unknown or imperceptible to the base station  3320 . Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer&#39;s  3310  measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software  3311 ,  3331  causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection  3350  while it monitors propagation times, errors etc. 
       FIG. 11  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 9  and  FIG. 10 . For simplicity of the present disclosure, only drawing references to  FIG. 7  will be included in this section. In a first action  3410  of the method, the host computer provides user data. In an optional subaction  3411  of the first action  3410 , the host computer provides the user data by executing a host application. In a second action  3420 , the host computer initiates a transmission carrying the user data to the UE. In an optional third action  3430 , the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth action  3440 , the UE executes a client application associated with the host application executed by the host computer. 
       FIG. 12  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 9  and  FIG. 10 . For simplicity of the present disclosure, only drawing references to  FIG. 12  will be included in this section. In a first action  3510  of the method, the host computer provides user data. In an optional subaction (not shown) the host computer provides the user data by executing a host application. In a second action  3520 , the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third action  3530 , the UE receives the user data carried in the transmission. 
       FIG. 13  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 9  and  FIG. 10 . For simplicity of the present disclosure, only drawing references to  FIG. 13  will be included in this section. In an optional first action  3610  of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second action  3620 , the UE provides user data. In an optional subaction  3621  of the second action  3620 , the UE provides the user data by executing a client application. In a further optional subaction  3611  of the first action  3610 , the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third subaction  3630 , transmission of the user data to the host computer. In a fourth action  3640  of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure. 
       FIG. 14  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 9  and  FIG. 10 . For simplicity of the present disclosure, only drawing references to  FIG. 14  will be included in this section. In an optional first action  3710  of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second action  3720 , the base station initiates transmission of the received user data to the host computer. In a third action  3730 , the host computer receives the user data carried in the transmission initiated by the base station. 
     When using the word “comprise” or “comprising” it shall be interpreted as non-limiting, i.e. meaning “consist at least of”. 
     The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.