Provision of communication services to users via I / O devices

Abstract

A user terminal emulation server (100) for providing communication services to a user (UserTag#1) via one or more input and / or output (I / O) user devices (130). The user terminal emulation server (100) is configured to register user information with a network entity (150) providing the communication services and predict a likelihood that the user will be in proximity to the I / O user device. The user terminal emulation server (100) is further configured to determine a discontinuous reception (DRX) setting based on the predicted likelihood that the user will be in proximity to the I / O user device and configure the I / O user device to use the DRX setting to receive downlink wireless communications from a radio access network (RAN) associated with the communication service. Related methods and computer program products are disclosed.

Description

Technical Field

[0001] The present disclosure relates to a user terminal emulation server for providing a communication service to a user via one or more input and / or output (I / O) user devices, a method of a user terminal emulation server for providing a communication service to a user via one or more I / O user devices, and a corresponding computer program product.

Background Art

[0002] The market for user terminals is being driven by the desire to provide users with increasingly advanced communication capabilities and other operational features within the constraints of a portable handheld form factor. The development requirements for user terminals are becoming increasingly complex as designers are required to integrate a more diverse user interface and advanced operational features within a portable handheld form factor. The advancement of operational features requires more highly integrated and faster processing circuits as circuit density increases, which is becoming increasingly difficult under cost and power consumption constraints.

[0003] This comprehensive feature-rich approach to user terminal development does not meet all the myriad different desires of consumers. Also, the expectations of today's always-connected society make users feel that if they do not keep their user terminals within reach with care, they may not be able to receive or initiate communication services at an appropriate time.

[0004] Several techniques have been proposed that seek to replace a conventional user terminal with another type of user interface that can interface with server-based services. For example, Sun Microsystems has proposed a thin client stateless terminal that a user can access to user applications run by a server. The terminal authenticates the user, allows the user to remove the smart card (logging the user off one terminal) to pause the session, and then allows the user to insert the smart card into any other terminal (logging the user on the other terminal) to resume the session immediately from where the user interrupted it, and includes an integrated smart card reader that operates to enable this.

SUMMARY OF THE INVENTION

[0005] Various embodiments disclosed herein are directed to providing a technique for server-based emulation of a user terminal that uses a discontinuous reception (DRX) setting to receive downlink wireless communication from a radio access network (RAN) associated with a communication service, where the DRX setting is determined based on a predicted likelihood that the user will come close to each of the I / O user devices.

[0006] Some embodiments relate to a user terminal emulation server for providing a communication service to a user via one or more I / O user devices. The user terminal emulation server is configured to register user information with a network entity that provides the communication service and to predict a likelihood that the user will come close to an I / O user device. The user terminal emulation server is further configured to determine a DRX setting based on the predicted likelihood that the user will come close to an I / O user device and to configure the I / O user device to use the DRX setting to receive downlink wireless communication from a radio access network (RAN) associated with the communication service.

[0007] Some other related embodiments relate to a method of a user terminal emulation server for providing communication services to a user via one or more I / O user devices. The method includes registering user information with a network entity that provides the communication service and predicting a likelihood that the user will come close to an I / O user device. The method further includes determining a DRX setting based on the predicted likelihood that the user will come close to an I / O user device and configuring the I / O user device to use the DRX setting to receive downlink wireless communication from a RAN associated with the communication service.

[0008] Some other related embodiments relate to a computer program product including a non-transitory computer-readable medium storing program instructions executable by at least one processor of a user terminal emulation server for performing operations for providing communication services to a user via one or more I / O user devices. The operations include registering user information with a network entity that provides the communication service and predicting a likelihood that the user will come close to an I / O user device. The operations further include performing a DRX setting based on the predicted likelihood that the user will come close to an I / O user device and configuring the I / O user device to use the DRX setting to receive downlink wireless communication from a RAN associated with the communication service.

[0009] Some potential advantages of these and other embodiments herein include that the user terminal emulation server can actively manage the power consumption and responsiveness of one or more I / O user devices for downlinking communications from the RAN while the communication service is not yet being used, based on whether and / or the likelihood that the user will come close to one or more I / O user devices. Exemplary communication services that can be provided by a network entity via one or more I / O user devices can include, but are not limited to, Voice over IP and / or Video over IP calls (e.g., Skype, Microsoft Teams, etc.), streaming media (e.g., Netflix, HBO, Hulu, etc.), online games, and the like. I / O user devices can include, but are not limited to, wireless discontinuous reception (DRX)-capable (e.g., 3GPP LTE and / or 5G New Radio-capable) televisions, display monitors, conference phones, speakerphones and / or display devices for connected cars, stand-alone speakers, stand-alone microphones, surveillance cameras, smart home appliances (e.g., display devices for refrigerators or thermostats), keyboards, etc., which are becoming almost ubiquitous everywhere following the Internet of Things (IoT) revolution. The I / O user device can operate in a DRX mode cycle between a low power consumption mode in which the I / O user device cannot receive downlink wireless communications from the RAN and a high power consumption mode in which the I / O user device can receive downlink wireless communications from the RAN. The user terminal emulation server controls the DRX settings used by the I / O user device based on the predicted likelihood that the user will come close to the I / O user device.For example, based on the likelihood that a user will be likely to approach an I / O user device within, for example, a threshold time, the user terminal emulation server can increase the frequency of downlink reception opportunities and, based on the likelihood that the user will be less likely to approach the I / O user device, set the DRX configuration to reduce the frequency of active reception opportunities. Thus, as the user approaches the I / O user device, the user terminal emulation server can change the DRX configuration to enable the I / O user device to more quickly receive and use downlink transmissions from the RAN. Actively managing the DRX configuration of the I / O user device in this way can 1) extend the operating life of the I / O user device on battery power by optimizing power consumption, 2) optimize the consumption of processing resources and memory resources used to monitor downlink RAN communications, and 3) reduce air interface signaling by enabling a faster transition to the DRX mode that reduces measurement signaling from the UE to the network.

[0010] Other servers, methods, and corresponding computer program products according to embodiments of the subject matter of the present invention will be or will become apparent to those of ordinary skill in the art upon consideration of the following drawings and detailed description of the invention. All such additional servers, methods, and corresponding computer program products are included within the scope of the present disclosure, are intended to be covered by the present invention, and are protected by the accompanying claims. It is also intended that all embodiments disclosed herein can be implemented in any manner and / or in combination, separately or in combination.

[0011] As an example, aspects of the present disclosure are shown, which are not limited to the accompanying drawings.

Brief Description of the Drawings

[0012]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

DETAILED DESCRIPTION OF THE INVENTION

[0013] Next, the present inventive concept will be described in more detail below with reference to the accompanying drawings showing examples of embodiments of the present inventive concept. However, the present inventive concept may be embodied in many different forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the various inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be implicit in or used in another embodiment.

[0014] Various embodiments disclosed herein are directed to providing a user terminal emulation server that emulates a user terminal using an individual I / O user device or a set of I / O user devices having user interface (UI) capabilities necessary to provide a user with the ability to use communication services provided by a network entity, for example as cloud computing resources, in proximity to the user. These embodiments can predict the likelihood that a user will come into proximity with an I / O user device or a set of I / O user devices. When the user arrives, the I / O user device or group of I / O user devices can be used to provide the user with the communication services of the network entity or can be made more immediately available to provide the communication services.

[0015] The user can receive and initiate communication services without the need for a conventional user terminal with comprehensive and rich functions, i.e., a conventional smartphone, mobile phone, tablet computer, etc. The user terminal emulation server can adaptively combine the available UI capabilities of the I / O user device that is predicted to come close to the user in order to support the provision of communication services to the user before the user gets close to the I / O user device. Whenever it is predicted that the I / O user device will come close to the user, by dynamically allocating the I / O user interface capabilities of the I / O user device, it is possible to provide some UI functions to the user during the communication service, enabling the efficient and flexible use of existing hardware such as a TV, display monitor, conference phone, speakerphone and / or the display device of a connected car, a stand-alone speaker, a stand-alone microphone, a surveillance camera, smart home appliances (e.g., the display device of a refrigerator or thermostat), a keyboard, etc. As a result, the user's need to carry an expensive and comprehensive user terminal, such as a smartphone, that includes all necessary UI functions, display devices, keyboards, speakers, etc., is reduced or eliminated. Instead, the user can carry a hardware device called a "UserTag" that operates to identify the user with respect to one or more I / O user devices via a wireless communication interface such as a Near Field Communication (NFC) interface.

[0016] Since the features and capabilities that form the user terminal in various embodiments disclosed herein are not restricted to the domain of mobile phone manufacturers, they may disrupt the conventional handset-centric mobile communication industry. The user terminal emulation server can act to provide a software-based user terminal, which may also be referred to as SoftUE or a user terminal emulation application operated by the user terminal emulation server.

[0017] In accordance with various 3GPP LTE standards, since the user device, also called the user equipment (UE) in 3GPP standards, has no information on how or when the radio access network (RAN) transmits any downlink data for reception by the user device, it must monitor the PDCCH (Physical Downlink Control Channel) for all subframes. One way to enable the user device to conserve energy is to operate in discontinuous reception (DRX), whereby the user device alternates between a period of low power consumption mode (also called sleep mode), controlled by the RAN, and another period of high power consumption mode (also called wake-up mode). During the low power consumption mode time (e.g., sleep mode), the user device cannot receive downlink wireless communication from the RAN (e.g., the transceiver circuit of the user device is powered off). In contrast, during the high power consumption mode (e.g., wake-up mode), the user device can receive downlink wireless communication from the RAN (e.g., the user device monitors the downlink wireless communication from the RAN via the transceiver circuit).

[0018] Various embodiments of the present disclosure further aim to actively manage the power consumption and responsiveness of one or more I / O user devices to downlink communications from a RAN when not yet used by a user for communication services, such as when the user is or is likely to be in proximity to one or more I / O user devices. In some embodiments, a user terminal emulation server determines a DRX setting based on a predicted likelihood that the user will come into proximity to an I / O user device, and configures the I / O user device to use the DRX setting to receive downlink wireless communications from the RAN related to a communication service. The user terminal emulation server can increase the frequency of downlink reception opportunities based on a high likelihood that the user will come into proximity to the I / O user device, for example, within a threshold time, and decrease the frequency of active reception opportunities based on a low likelihood that the user will come into proximity to the I / O user device, so as to configure the DRX setting of the I / O user device. Thus, as the user approaches the I / O user device, the user terminal emulation server predicts an increasing likelihood that the user will come into proximity to the I / O user device, and responsively changes the DRX setting to increase the frequency and / or time available for the I / O user device to receive downlink wireless communications from the RAN, enabling the I / O user device to more quickly receive and use downlink transmissions from the RAN. Actively managing the DRX setting of the I / O user device in this way can 1) extend the operation of the I / O user device on battery power by optimizing power consumption, 2) optimize the consumption of processing and memory resources used to monitor downlink RAN communications, and 3) reduce air interface signaling by enabling a faster transition to a DRX mode that reduces measurement signaling from the UE to the network.

[0019] FIG. 1 shows a system having a user terminal emulation server 100 that operationally uses individual I / O user devices 130 or an integrated set of I / O user devices 130 in proximity to a user to logically emulate a user terminal that provides a communication service via one or more network entities 150, according to some embodiments of the present disclosure. FIG. 11 is a flowchart of operations that may be performed by the user terminal emulation server 100 to determine a DRX setting based on a predicted likelihood that a user will come into proximity to an I / O user device 130 and configure the I / O user device 130 to use the DRX setting to receive downlink wireless communications from a RAN (220, FIG. 2) associated with the communication service.

[0020] Referring to FIGS. 1 and 11, the user terminal emulation server 100 may be cloud computing resources remotely network-connected to the I / O user devices 130, or may be closer, e.g., within edge computing resources, on a shared network with the I / O user devices 130. The user terminal emulation server 100 is configured to register user information (1100) with a network entity 150 that provides a communication service to the user. As will be described in more detail below, the user information can include, but is not limited to, any one or more of a user identifier, user qualification information for accessing the communication service (e.g., a user ID and password), a phone number, a mobile subscriber identification number (MSIN), a network address of a user terminal emulation application 110 associated with the user, etc. Exemplary communication service functions 142 provided by the network entity 150 can include, but are not limited to, voice over IP and / or video over IP conferencing services (e.g., Skype, Microsoft Teams, etc.), streaming media services (e.g., Netflix, HBO, Hulu, etc.), game services (e.g., online game applications), etc.

[0021] The user terminal emulation server 100 is further configured to predict (1102) the likelihood that a user will come close to one or more I / O user devices 130, and determine a DRX setting (1104) based on the predicted likelihood that the user will come close to one or more I / O user devices 130. The user terminal emulation server 100 configures one or more I / O user devices 130 to use the DRX setting to receive downlink wireless communication from a RAN (220 in FIG. 2) related to a communication service (1106). An example of the type of DRX setting will be further described below.

[0022] The user can carry a hardware tag, the general term "UserTag" in FIG. 1, which can transmit a unique user identifier through a communication interface such as a short-range communication interface (e.g., Bluetooth, Bluetooth low energy (BLE), near-field communication (NFC), RFID, etc., or a combination thereof) for reception by one or more of the I / O user devices 130 close to the user. One type of UserTag can be a simple stand-alone type of electronic device that has limited ability to transmit an identifier through a short-range communication interface. Another type of UserTag can be a smartphone or smartwatch with cellular connectivity that transmits cellular identification information (e.g., from a SIM card) or application identification information through a cellular interface or a short-range communication interface.

[0023] In an exemplary embodiment, which will be described in further detail below, the user terminal emulation server 100 can operate to provide a seamless handoff of a video conferencing service provided to a first user at that time from a first I / O user device 130 to a second I / O user device 130 via a network entity 150, for example, when the first user walks in a corridor of a building. For example, the first I / O user device 130 may be located at the entrance to the corridor of the building, and the second I / O user device 130 may be located further along the corridor of the building. The user terminal emulation server 100 determines that the first user is then in proximity to the first I / O user device 130 based on receiving a report from the first I / O user device 130 that provides a sensed UserTag#1 identifier associated with the first user. In response to an incoming request from the network entity 150 or the first user to establish a video conferencing service, the user terminal emulation server 100 uses the I / O user interface of the first I / O user device 130 to provide the video conferencing service.

[0024] Based on being configured to know the relative positions of the first and second I / O user devices 130, and / or based on learning such as having been observed in the past that the user is likely to come into proximity with the second I / O user device 130 within a threshold time after coming into proximity with the first I / O user device 130, the user terminal emulation server 100 predicts the likelihood that the user will come into proximity with the second I / O user device 130. Alternatively or additionally, the user terminal emulation server 100 may predict the likelihood that the user will come into proximity with the second I / O user device 130 based on the user's position being notified by a satellite-based positioning system (e.g., GNSS, GPS, etc.), a cellular-based positioning system, etc., and / or based on obtaining user movement information indicating the speed and / or direction of the user's movement with respect to the I / O user device 130.

[0025] The term "proximate" is used non - limitingly, for example, to refer to when a user has become close enough to an I / O user device such that the user can use one or more user interface (UI) capabilities of the I / O user device. For example, if a user is predicted to be within the audible range of a speaker, the user can be determined to be proximate to the speaker, which may depend on the output volume capabilities of the speaker. Similarly, a user can be determined to be proximate to a camera when the user is predicted to be within the field of view and / or range of the camera such that the user can be resolved from other objects within the video stream from the camera. In contrast, a user may be determined to be proximate to these or other I / O user devices if the user is predicted to be within a defined distance from the I / O user device or within a threshold time to reach the I / O user device.

[0026] Some embodiments are described in the context of a user moving relative to an I / O user device 130, but in some other embodiments, one or more of the I / O user devices 130 move relative to the user. For example, the camera and / or microphone of a flying or ground - moving drone can operate to transmit an uplink video stream and / or microphone audio stream of the user to the communication service function 140 of the network entity 150 via the RAN during an online meeting. Similarly, the speaker of a flying or ground - moving drone can operate to play a downlink audio stream received from the communication service function 140 of the network entity 150 via the RAN to the user during an online meeting.

[0027] The user terminal emulation server 100 can determine that the second I / O user device 130 has an I / O user interface that meets the capability criteria enabling the first user to use the video conferencing service provided by the network entity 150, and can signal the second I / O user device 130 to prepare to use the I / O user interface to provide the video conferencing service for the first user. The user terminal emulation server 100 may start transferring video conferencing service traffic to the second I / O user device 130 before it is predicted that the first user will come close to the second I / O user device 130, or may start the transfer in response to being notified that the user has come close to the second I / O user device 130. The second I / O user device 130 may perform one of the following operations using the video conferencing service traffic: start playing the video conferencing service traffic via the I / O user interface, buffer the video conferencing service traffic for subsequent playback via the I / O user interface in response to the user coming close to the second I / O user device 130, and discard the video conferencing service traffic until the user comes close to the second I / O user device 130. Alternatively, the user terminal emulation server 100 may start transferring video conferencing service traffic to the second I / O user device 130 in response to being notified that the user has come close to the second I / O user device 130.

[0028] In the illustrated example of FIG. 1, the user terminal emulation server 100 receives a report from one of the I / O user devices 130 within area 131 indicating that UserTag#1 associated with the user is then in proximity to that I / O user device 130. The user terminal emulation server 100 can responsively identify the set of I / O user devices that are then in proximity to the user. The user terminal emulation server 100 can also predict, based on one or more of the operations disclosed below for predicting the likelihood that the user will come into proximity with an I / O user device, that the user is likely to come into proximity with a set of other I / O user devices 130 within area 132, for example, within a threshold time. The user terminal emulation server 100 can also identify, in area 133, a set of I / O user devices 130 that are not predicted to come into proximity with the user.

[0029] The user identification information can additionally or alternatively be operationally determined, for example, by using biometric authentication operations performed by one or more of the I / O user devices 130. Biometric authentication operations can include, but are not limited to, one or more of voice recognition, image / face recognition, eye recognition, fingerprint recognition, or combinations thereof. The user identification information can be determined based on authentication information provided by the user, for example, upon login to an application or account. The user identification information can also be determined from information provided by a mobile phone, such as information from a subscribed SIM, and the proximity of the user of the mobile phone to one or more of the I / O user devices 130 can be determined using the mobile phone's near field communication (NFC) capabilities.

[0030] A user identifier (e.g., a UserTag identifier) and a user terminal application can be logically associated with each other within the database repository 120 during the user registration process or as part of another startup process. For example, during the user registration process, a user is associated with a UserTag identifier for a physical UserTag given (e.g., purchased) to the user, and is associated with a user terminal application that emulates a user terminal (e.g., a mobile phone that provides cellular service or an over-the-top voice over IP communication service) having a defined capability, and can obtain an account login identifier (acting as a user identifier) registered in the database repository 120.

[0031] The operations that can be performed by the user terminal emulation server 100 to provide communication services to a user will be described below with further reference to FIG. 6. Referring to FIGS. 1 and 6, the user terminal emulation server 100 maintains a database repository 120 that can identify the network address of the I / O user device 130 and identify the UI capabilities of the I / O user device 130 based on the content of the received registration message (700). The capabilities of the I / O user device 130 may be logically arranged in the repository 120 based on the type of UI capabilities provided, e.g., display device, microphone, ear speaker (e.g., Bluetooth ear speaker), speaker, keyboard, and may be further arranged based on the quality of service characteristics provided by the UI capabilities (e.g., mono or stereo speaker, maximum volume of the speaker, screen size of the display, maximum resolution of the display, etc.). According to various embodiments, the database repository 130 can identify which I / O user devices 130 support DRX (i.e., are capable of DRX operations to receive downlink wireless communication from the RAN), identify the DRX settings then set for the I / O user device 130, and / or identify which DRX settings of the I / O user device 130 can be reset by the user terminal emulation server 100 via the RAN.

[0032] The I / O user device 130 can communicate a registration message specifying its network address (e.g., IP address and port number, MAC address, fully qualified domain name (FQDN), and / or another network address), UI capabilities, its then DRX settings, and / or reconfigurable DRX settings to the user terminal emulation server 100 in response to an initial setup operation, in response to being connected to a new communication network, and / or in response to another defined event for triggering the generation of a registration message. The registration message can identify the geographical location of the I / O user device 130, which can be stored in the database repository 120. The I / O user device 130 can communicate with the server 100 via a data network (e.g., the Internet and / or a private network) using another wireless transceiver such as a cellular transceiver (e.g., 3GPP LTE and / or 5G New Radio compatible) and / or a WiFi transceiver, a Bluetooth transceiver, an optical communication transceiver (LiFi), and / or another RF or optical communication transceiver.

[0033] The user terminal emulation server 100 can receive a registration message from the I / O user device 130 using, for example, the Session Initiation Protocol (SIP) / Session Description Protocol (SDP). The I / O user device 130 can respond to the occurrence of a power-on or another defined operational event by communicating the registration message to the user terminal emulation server 100.

[0034] The user terminal emulation server 100 registers user information with a network entity 150 that provides a communication service (702 in FIG. 6 and 1100 in FIG. 11). The user information can include any one or more of a user identifier, user qualification information for accessing the communication service (e.g., user ID and password), a telephone number, a mobile subscriber identification number, the network address of the user terminal emulation application 110 associated with the user, etc. The network entity 150 provides various communication service functions 140 that can correspond to, for example, an over-the-top voice over Internet protocol (VoIP) service, a video conferencing service (e.g., Teams, Skype, etc.), a media content streaming service (e.g., Netflix, HBO, Hulu, etc.), a game service (e.g., an online game application), a cellular communication service, and the like. The user terminal emulation application 110 is executed by the user terminal emulation server 100 and can execute one or more applications that are normally executed by a smartphone, such as a VoIP service application, a video conferencing service application, a media content streaming application, an online game application, a cellular communication service, etc.

[0035] As shown in FIG. 1, in some embodiments, for each user for whom a communication service is to be provided, a different instantiation of the user terminal emulation application 110 can be hosted by the server 100 (i.e., the illustrated user terminal emulation applications #1 to #N corresponding to users 1 to N). The user terminal emulation application 110 can register and address one of the user terminal emulation applications instantiated for the user using the network entity 150, and then initiate a communication service with the user via the user terminal emulation application instantiated for the user.

[0036] When the communication service function 140 of the network entity 150 is a VoIP service, the operation of registering user information (702 in FIG. 6 and 1100 in FIG. 11) can include registering the network address of the user terminal emulation application associated with the user and / or the user qualification information for accessing the VoIP service with the network entity 150, which can be a network server of the VoIP communication service provider.

[0037] When the communication service function 140 of the network entity 150 is a cellular communication service, the operation of registering user information (702 in FIG. 6 and 1100 in FIG. 11) can include registering the network address of the user terminal emulation application associated with the user and / or the user identification information (e.g., telephone number and / or mobile subscriber identification number) with the network entity 150, which can be another network node of the core network operated by the home subscriber server (HSS) or the cellular communication service provider.

[0038] The user terminal emulation server 100 receives a communication request (704) from the network entity 150 asking to establish a communication service with the user and the user terminal that the user is requesting, for example, a mobile phone, a computer equipped with an online meeting application, a game application, etc. In response to the communication request, the user terminal emulation server 100 identifies a set of I / O user devices 130 identified by the repository 120 that are determined to be close to the user's location or are predicted to be close to the user. The user terminal emulation server 100 further determines that the set of I / O user devices meets the combination ability criterion that the set of I / O user devices is combinable to provide a combined I / O user interface for the user to interface with the user terminal emulation application 110 to provide the communication service, based on the UI capabilities identified by the repository 120 for the set of I / O user devices and based on the content of the communication request.

[0039] Based on the determination that the set of I / O user devices meets the combination ability criteria, the user terminal emulation server 100 provides, via the network entity 150, a communication session between the user terminal emulation application 110 and the I / O user devices in the set, and a communication session between the user terminal emulation application 110 and the requesting user terminal (708). The communication request 704 received by the user terminal emulation application 110 may include a display of the minimum UI capabilities to be provided to the user during the communication service, such as only a speaker, a combination of a speaker and a microphone, only a display, a combination of a display device, a speaker, and a microphone, etc. Thereby, the combination ability criteria used by the server 100 to determine whether a communication service can be provided and by which set of I / O user devices it can be provided may be defined based on the minimum UI capabilities indicated by the communication request.

[0040] Thereby, the user terminal emulation server 100 forwards the communication traffic received from at least one of the I / O user devices in the set to the requesting user terminal via the network entity 150 (710). Further operations are performed for each data type received as communication traffic from the requesting user terminal (712), and the operations are based on matching the characteristics of the data type to the UI capabilities specified by the repository 120 for one of the I / O user devices, selecting one of the I / O user devices from the set of I / O user devices (714), and then forwarding the data of that data type to the network address of the selected one of the I / O user devices.

[0041] Server 100 can also combine (716) data streams received from I / O user devices within a set and transfer the combined data stream to the requesting user terminal, for example, via network entity 150.

[0042] User terminal emulation server 100 (e.g., application 110 or the I / O user device handler described below) may be responsible for tracking which I / O user device is then close to the user's then location. FIG. 7 is a flowchart of the corresponding operation. Server 100 can receive (800) a presence report from an individual one of the I / O user devices, including its network address and an identifier of the user determined to be close by the I / O user device. For example, the I / O user device can read a hardware tag, also referred to herein as a "UserTag", via an NFC communication interface, sense biometric information from the user, identify the user via face recognition performed on a video stream from a camera, and / or detect the presence of the user and perform other operations to identify the user. In response to the presence report, server 100 updates repository 120 to indicate (802) which user identifiers are close to which of the I / O user devices.

[0043] Referring further to the exemplary system of FIG. 1, the user terminal emulation server 100 predicts the likelihood that a user carrying UserTag#1 will come close to various I / O user devices through the operation of the user terminal emulation application_#1 100. For example, based on receiving a report from one of the I / O user devices 130 that includes the identifier of UserTag#1, the user terminal emulation server predicts that the likelihood that the user is then close to the set of I / O user devices 130 within area 131 is 100%. The user terminal emulation server 100 determines a first set of DRX settings for the I / O user devices 130 within area 131 based on the predicted likelihood and can configure the I / O user devices 130 within area 131 to operate using the first set of DRX settings. Since the user is predicted to be then close to the set of I / O user devices within area 131, the first set of DRX settings is configured to give the I / O user devices 130 within area 131 a relatively high wake-up rate, for example, to listen for download transmissions from the RAN. Exemplary DRX settings that can be configured for the I / O user devices will be described in further detail below.

[0044] The user terminal emulation server 100 can provide a combined I / O user interface used by the user among a newly started incoming communication service, a newly started outgoing communication service, or an ongoing established communication service through the operation of the user terminal emulation application_#1 100 using the set of I / O user devices 130 within area 131 at that time via the network entity 150.

[0045] Similarly, based on the prediction that the user is then in close proximity to area 131 and one or more prediction operations further described below, the user terminal emulation server predicts that there is a 75% likelihood that the user will, for example, come into proximity to a set of other I / O user devices 130 within area 132 within a threshold time. The user terminal emulation server 100 determines a second set of DRX settings for the I / O user devices 130 within area 132 based on the predicted likelihood, and can configure the I / O user devices 130 within area 132 to operate using the second set of DRX settings. Since the user is predicted to be less likely to come into proximity to the set of I / O user devices within area 132 and / or to come into proximity in the future within the threshold time, the second set of configured DRX settings can give the I / O user devices 130 within area 132 a low wake-up rate for listening for download transmissions from the RAN, for example, as compared to the configuration by the first set of DRX settings.

[0046] Similarly, based on the prediction that the user is then in close proximity to area 131 and one or more prediction operations further described below, the user terminal emulation server predicts that there is a 10% likelihood that the user will, for example, come into proximity to a set of other I / O user devices 130 within area 133 within a threshold time. The user terminal emulation server 100 determines a third set of DRX settings for the I / O user devices 130 within area 133 based on the predicted likelihood, and can configure the I / O user devices 130 within area 133 to operate using the third set of DRX settings. Since the user is predicted to be even less likely to come into proximity to the set of I / O user devices within area 133 as compared to the set of I / O user devices within area 132, the third set of configured DRX settings can give the I / O user devices 130 within area 133 a relatively low wake-up rate for listening for download transmissions from the RAN, for example, as compared to the configuration by the second set of DRX settings.

[0047] As described above, the communication request received at 704 that requests the establishment of a communication service with a specified user can be initiated by network entity 150 using the user's identification information and, optionally, the network address of the user terminal emulation application previously registered with network entity 150. However, the communication request may also or alternatively be generated by one of the I / O user devices 130 in response to a command received from a nearby user. For example, a user can cause a user interface provided by one of the I / O user devices 130 to initiate a combined audio and video call with another user. User terminal emulation server 100 receives the communication request along with the identification information of the user that can be sensed via UserTag. Application 110 performs the operations of specifying 706, providing 708, forwarding 710, selecting 712, and combining 716 described above with respect to FIG. 6 to initiate and operate a communication service between that user and other users via network entity 150.

[0048] Examples of additional systems and related operations are described herein that further illustrate how I / O user devices having various UI capabilities can be operationally combined to provide a combined UI that can be used by a user to meet the communication requirements of a communication service.

[0049] Regarding an embodiment example which is one of a set of I / O user devices 130 within a set that can play an audio stream received by a speaker device, and is another one of the set of I / O user devices 130 within a set where a microphone device can sense audio and output a microphone stream, further exemplary operations are described. Operations by the user terminal emulation server 100 (e.g., by one of the user terminal emulation applications) include updating the repository 120 based on the content of registration messages from the speaker device and the microphone device to identify the network addresses of the speaker device and the microphone device, and also identifying the UI capabilities of the speaker device as having speaker capabilities and the UI capabilities of the microphone device as having microphone capabilities. The speaker UI capabilities can identify the number of operating speakers, the volume capabilities of the output sound, and / or other operational characteristics. The microphone UI capabilities can identify the number of provided microphones, the sensitivity of the microphones, and / or other operational characteristics. The speaker device and the microphone device are each determined to be in proximity to the location of the user (UserTag#1) or are predicted to be in proximity, and further, based on the UI capabilities identified by the repository 120, they are determined to belong to a set of I / O user devices that can be combined to provide a combined I / O UI to the user to interface with the user terminal emulation application 110 to provide a communication service. Based on the determination that the speaker device and the microphone device meet the combined capabilities criteria, further operations are performed to transfer the microphone stream received from the microphone device to the user terminal that has requested it (e.g., via the network entity 150).When an audio stream is received as communication traffic from a requesting user terminal, in operation, the speaker device is selected based on matching the audio characteristics of the audio stream to the speaker capabilities specified by the repository for the speaker device, and then the audio stream is transferred to the network address of the speaker device.

[0050] In this exemplary embodiment, if one of the I / O user devices within the set capable of displaying the received video stream is a display device, in operation, the repository 120 is updated based on the content of the registration message (700), the network address of the display device is identified, and the UI capabilities of the display device are identified as having display capabilities (706). The display UI capabilities can identify the screen display size, aspect ratio, pixel resolution, supported video frame rate, whether the display device supports shared user support via a split-screen configuration, and / or other operational characteristics. The display device is also determined to be or predicted to be in proximity to the user's position within the set of I / O user devices, and based on the UI capabilities specified by the repository 120, is further determined to meet the combination ability criteria such that it can be combined to provide a combined I / O UI to the user to interface with the user terminal emulation application 110 to provide a communication service. Based on the determination that the speaker device, display device, and microphone device meet the combination ability criteria, further operations are performed. In response to receiving a video stream as communication traffic from the requesting user terminal, the display device is selected based on matching the video characteristics of the video stream to the display capabilities specified by the repository 120 for the display device, and then the video stream is transferred to the network address of that display device.

[0051] In this embodiment example, when performing the operation of transferring an audio stream and a video stream to the network address of a speaker device and the network address of a display device respectively, if audio data and video data are received within the same stream from a user terminal that requests through a first communication session, separating the audio data from the video data, transferring the audio data to the network address of the speaker device through a second communication session, and transferring the video data to the network address of the display device through the second communication session or a third communication session may be included.

[0052] In this embodiment example, when the camera device is one of the I / O user devices within a set that can output a camera stream, the operation may include updating the repository 120 based on the content of the registration message to identify the network address of the camera device and identifying the UI capabilities of the camera device as having camera capabilities. The camera UI capabilities can identify the number of camera pixels, image quality, light sensitivity, and / or other operational characteristics. The camera device is further identified as being a member of a set of I / O user devices that is determined to meet the combination ability criterion that it can be combined with other I / O user devices within the set to provide a combined I / O UI to the user to interface with the user terminal emulation application 110 and provide a communication service based on the UI capabilities identified by the repository 120 when it is determined that the camera device is close to the user's position or is predicted to be close to the user. Based on the determination that the camera device meets the combination ability criterion, further operations are performed to transfer the camera stream received from the camera device to the user terminal that requested it, for example, via the network entity 150.

[0053] For the operation of transferring the microphone stream received from the microphone device and the camera stream received from the camera device to the user terminal that requests them, through the first communication session, receiving the microphone stream from the microphone device, through the first communication session or the second communication session, receiving the camera stream from the camera device, combining the microphone stream and the camera stream into a combined stream, and through the third communication session, transferring the combined stream to the user terminal that requests it, for example, via the network entity 150, may be included.

[0054] In this exemplary embodiment, when the keyboard device is one of the I / O user devices in a set capable of outputting key selection data in response to a user's key selection from among the keys of the keyboard device, the operation may include updating the repository 120 based on the content of the registration message to identify the network address of the keyboard device and also to identify the UI capabilities of the keyboard device as having keyboard capabilities. Keyboard device capabilities can identify the key count, an indication of whether the keyboard is a physical keyboard or a touch-sensitive input device, and / or other keyboard capabilities. The keyboard device is further identified as being a member of a set of I / O user devices that is determined to meet a combination capability criterion such that it can be combined with other I / O user devices in the set to provide a combined I / O UI to the user for interfacing with the user terminal emulation application 110 to provide a communication service based on the UI capabilities identified by the repository 120, when the keyboard device is determined to be proximate to or predicted to come proximate to the user's location. Based on the determination that the keyboard device meets the combination capability criterion, further operations are performed to identify a command formed by the key selection data received from the keyboard and to perform a pre-specified operation triggered based on the receipt of the identified command.

[0055] Operations for transferring key selection data received from the keyboard device and the microphone stream received from the microphone device may include receiving the key selection data from the keyboard device through a first communication session, receiving the microphone stream from the microphone device through the first communication session or a second communication session, combining the key selection data and the microphone stream into a combined stream, and transferring the combined stream through a third communication session to a user terminal requesting it, for example via the network entity 150.

[0056] Figure 2 is a block diagram showing user terminal emulation server 100 as an element of operator service node 202 within cellular system 200. Referring to FIG. 2, the communication service function of network entity 140 (FIG. 1) may be provided by operator service node 202 or may be delivered by a remote server through external infrastructure 240, such as the Internet and / or a private network. User terminal emulation server 100 may be implemented, for example, in radio access network 220 for edge computing to provide faster responsiveness, or may be implemented within another node of cellular system 200. User terminal emulation server 100 may include an I / O user device handler (IODH) 212, a control function (CF) 214, an instantiated user terminal emulation application 110, and a service gateway (GW) 216. User terminal emulation application 110 may execute one or more applications normally executed by a smart phone, such as a Netflix application, a Facebook application, a Skype application, an Internet browser application, etc.

[0057] The IODH212 can manage the I / O user device, such as taking care of maintaining the repository 120 (700 in FIG. 7) and / or registering the user, and in some cases also registering the user terminal emulation application 110 (702 in FIG. 7). For example, the IODH212 can act to register the IP address of the Skype application and the user's Skype name with the Skype service server, which is executed by or interfaced with the user terminal emulation application 110. The CF214 can be responsible for assigning IP addresses to each user terminal emulation application 110. The IP addresses to be assigned by the CF214 can be received from the core network 210 functions such as the PDN-GW. The service GW216 can interconnect the user terminal emulation server 100 with the PSTN network, the packet data network gateway of the 3GPP (3rd Generation Partnership Project) system, etc. The cellular system 200 can include a core network 210 having a home subscriber server (HSS), a policy and charging rules function (PCRF), a gateway (GW), and a mobility management entity (MME) that provides control signaling related to mobile terminal mobility and security for wireless access. The HSS includes subscriber-related information and provides functions for user authentication and support for user access to the system. The PCRF enables QoS control for each data flow and radio bearer by setting QoS criteria for each data flow based on operator-set policies and subscriber information. The GW can include a serving GW (S-GW) and a packet data network GW (PDN-GW). The S-GW interconnects the core network 210 and the radio access network 220 and forwards incoming and outgoing packets. The PDN-GW interconnects the core network 210 and an external infrastructure 240 such as the Internet, assigns IP addresses, and performs policy control and charging.

[0058] Some I / O user devices with cellular communication capabilities can communicate with the operator service node 202 via the core network 210 and with, for example, an eNB or other radio access node of the radio access network 220. In the system of FIG. 2, the user terminal emulation server 100 can set up a set of communication services between a selected set of I / O user devices that are determined to be close to the user or are predicted to become close to the user and a remote user terminal via the cellular system 200.

[0059] In the example of FIG. 2, the user terminal emulation server 100 includes a proximity prediction and DRX setting module 250 that predicts the likelihood that the user will come close to an I / O user device (operation 1102 in FIG. 11), determines a DRX setting based on the predicted likelihood that the user will come close to an I / O user device (operation 1104 in FIG. 11), and performs operations to configure the I / O user device to use the DRX setting to receive downlink wireless communication from the RAN 220 (operation 1106 in FIG. 11). The module 250 can include a machine learning module 252 in the operation of predicting the likelihood that the user will come close to various I / O user devices, as will be described in more detail below. The DRX setting can be communicated to the RAN 220 to configure one or more of the I / O user devices.

[0060] In the example described above with reference to FIGS. 1 and 2, the proximity prediction and DRX setting module 250 predicts that the user is then in proximity to an I / O user device within area 131 and determines a first set of DRX settings, and the first set of DRX settings is communicated via path 260 to RAN 220 for an eNB to be used to configure the DRX operation of the I / O user device within area 131. The proximity prediction and DRX setting module 250 also predicts that there is a 75% likelihood that the user will come into proximity to another set of I / O user devices 130 within area 132, for example, within a threshold time, and determines a second set of DRX settings communicated via path 260 to RAN 220 for another eNB to be used to configure the DRX operation of the I / O user devices within area 132.

[0061] The above and other operations are described in further detail in the context of two different example "use cases": 1) an incoming scenario, and 2) an outgoing scenario.

[0062] Use Case 1: Incoming Scenario

[0063] This use case pertains to a user, identified with a UserTag or otherwise, who is predicted to be in proximity to, or to come into proximity to, an I / O user device 130 having various UI capabilities within area 131 when an incoming call is received by the user terminal emulation server 100. The operations are described below in the context of identifying the user through a physical UserTag carried by the user, but these operations are not so limited and may be used in any other way of identifying the user, such as by sensing biometric information that identifies the user.

[0064] The user terminal emulation application 110 can be instantiated or become active in response to an incoming (service, session) targeted at UserTag. The user terminal emulation application 110 can identify the subscriber associated with UserTag (i.e., the physical user) and the preferred communication method defined by the user (e.g., audio instead of video, audio and video, etc.), and can determine the UI capabilities of the I / O user device that are required to meet the UI capabilities that can be defined in the incoming communication session. The user terminal emulation application 110 can request the IODH to identify which I / O user devices 130 are close to or are predicted to be close to UserTag, and can further request the IODH to determine whether the identified I / O user devices 130 can be combined to meet the UI capabilities defined by the incoming communication session, or can determine this itself. The user terminal emulation application 110 and / or the IODH can receive an ACK or NACK regarding whether a sufficient set of I / O user devices 130 for providing the communication service can be used. In the case of an ACK, the IODH can also set the status of the I / O user devices 130 in the set to in use or about to be in use, so as to prevent another user terminal emulation application 110 from attempting to use the same I / O user devices 130 that it is using at that time. In the case of a NACK, the user terminal emulation application 110 and / or the IODH can variously start working to launch a reduced UI capability communication service according to the user settings. For example, in response to there being no display device available at that time, it can be made such that only audio-based communication is possible instead of a combination of audio and video.An example where there are no available display devices can occur when the only display device in proximity to the user is being used by another user to receive information from another user terminal emulation application during an ongoing communication service, or when there are no display devices in proximity to the user.

[0065] Figure 3 is a combined flowchart of the operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server according to some embodiments of the present disclosure. Referring to Figure 3, the UserTag enters a room and signals its presence to any capable I / O user device in the vicinity in that room using a discovery beacon signal (400). Alternatively, one or more of the I / O user devices may determine the presence of the UserTag by polling, such as by periodically transmitting a discovery beacon signal that triggers in response to signaling by the UserTag (402). The I / O user device that receives the signaling indicates the presence report of the UserTag to the IODH at the user terminal emulation server, along with the network address of the I / O user device (e.g., IP address, port number, MAC address, FQDN, etc.) (404). The user terminal emulation application corresponding to a particular user (i.e., the UserTag) is updated in relation to the detected presence of the user (406). The IODH can act to receive notifications from I / O user devices in the vicinity of the UserTag. Further UI capability discovery (synchronization) communication 410 occurs between the user terminal emulation server and the I / O user device that reported the presence of the user and / or between the user terminal emulation server and an I / O user device that is predicted to come into proximity to the user based on, for example, another one of the I / O user devices that is then in proximity to the user. The I / O user device is associated with the user in a repository with the corresponding join indication and combinable UI capabilities provided by the set of I / O user devices that are in proximity to or predicted to come into proximity to the UserTag.By operation 412, it has been found that here a user via a UserTag can reach into the system through a set of specified I / O user devices having specified UI capabilities (e.g., speaker yes / no, display yes / no, microphone yes / no, keyboard yes / no, etc.), thereby creating a logical virtualized user terminal through which the user can be provided with communication services. The user can initiate communication services through a touch screen, voice commands sensed by a microphone, performing predefined gestures observable by a camera, and / or other inputs given to one of the nearby I / O user devices.

[0066] In operation 414, an incoming session (e.g., a video call) from the user terminal requesting the request directed to the user (UserTag) arrives at the user terminal emulation server for the user with UserTag. In operation 416, the combinable UI capabilities of the available I / O user devices are compared with the UI requirements of the incoming session. If the UI requirements of the incoming session are not met by the combinable UI capabilities of the I / O user devices, the user terminal emulation server can renegotiate again for the required UI capabilities of the incoming session (e.g., audio only, audio and video, video only, etc.) (416). In contrast, if the UI requirements of the incoming session are met by the combinable UI capabilities of the I / O user devices, the user terminal emulation server prompts the user with UserTag to give a session request response (ACK / NACK) via one or more of the available I / O user devices (e.g., preselected answering devices). The user responds to prompt the user terminal emulation server by signaling to accept (ACK) or reject (NACK) the incoming session through the preselected answering device 420 (422). When an ACK is received, in operation 424, the audio stream from the requesting user terminal is transferred via one or more sessions to one of the I / O user devices within the set having speaker capabilities (426), and the video stream from the requesting user terminal is transferred via one or more sessions to another one of the I / O user devices within the set having display capabilities (426). A data stream received from one of the I / O user devices within the set through one or more sessions 429 is transferred to the requesting user terminal 430. When two or more data streams are received from the I / O user device through one or more sessions (429), the data streams can be combined into a combined data stream, and this combined data stream is transferred to the requesting user terminal (430).

[0067] The user terminal emulation server performs operation 428, where it continuously monitors for the presence of I / O user devices within area 131 and determines when one or more of the I / O user devices that can no longer be included as part of the combined UI capabilities provided during a communication session are no longer in proximity to the user. In response to a previous member of the set no longer being in proximity, the user terminal emulation server can instead use the UI capabilities of another I / O user device for the set used by the user in an ongoing communication session. As the user moves into area 132, the user terminal emulation server can substitute the UI capabilities of another I / O user device that is predicted to come into proximity to the user, determine updated DRX settings, and configure other I / O user devices within area 132 according to the updated DRX settings to prepare other I / O user devices to more quickly receive and use downlink communication from the serving eNB of RAN 220 associated with the ongoing communication session. The user terminal emulation server 100 can dynamically generate updated predictions of the likelihood that the user will come into proximity to or remain in proximity to various I / O user devices and dynamically update the DRX settings used for the various I / O user devices based on the updated predictions.

[0068] Use Case 2, Outgoing

[0069] This use case pertains to a UserTag - tagged user who is, or is predicted to come, in proximity to I / O user devices 130 with various UI capabilities within area 131 when an outgoing (communication session) is received by the user terminal emulation server 100. The I / O user devices 130 are associated with a specified user via the user terminal emulation server 100 that operates all of the communication sessions for that user, while the associated I / O user devices 130 are managed by the IODH.

[0070] The user terminal emulation application 110 can be instantiated or enabled in response to a request for a call by a user with a UserTag. The user can initiate a call through the touch screen, voice commands sensed by the microphone, performing a predefined gesture observable by the camera, and / or other inputs provided to the nearby I / O user device.

[0071] The user terminal emulation application 110 can identify the subscriber (i.e., the physical user) associated with the UserTag and the preferred communication method (e.g., audio instead of video, audio and video, etc.) defined by the user, and determine the UI capabilities of the I / O user device that are required to meet the UI capabilities that can be defined for outgoing calls. The user terminal emulation application 110 can identify to the IODH which I / O user device 130 is close to the UserTag within area 131, and further, for example, in response to an answer, inquire which other I / O user device 130 is predicted to come close to the user within area 132, etc. The user terminal emulation application 110 can further request the IODH to determine whether the identified I / O user device 130 and / or other I / O user devices 130 can be combined to meet the UI capabilities specified by the outgoing call, or can determine this itself. The user terminal emulation application 110 and / or the IODH can receive an ACK or NACK based on whether a sufficient set of I / O user devices 130 for providing the communication service can be used. In the case of an ACK, the IODH can also set the status of the I / O user devices 130 within the set to in use, so that another user terminal emulation application 110 does not attempt to utilize the same I / O user devices 130 that are then in use or will soon be in use. In the case of a NACK, the user terminal emulation application 110 and / or the IODH can variously start working to launch a reduced UI capability communication service according to user settings, for example, in response to there being no display device available at that time, making it possible to do only audio instead of the preferred sound and video (e.g., when being used by another user terminal emulation application 110 at that time or when there is nothing close to the UserTag or predicted to come close to the UserTag within the threshold time).

[0072] Figure 4 is a combined flowchart of the operation of transmission and the related data flow among UserTag, I / O user device, and user terminal emulation server according to some embodiments of the present disclosure. Referring to Figure 4, UserTag enters a room and signals its presence to any capable I / O user device in the vicinity in that room using a discovery beacon signal (500). Alternatively, one or more of the I / O user devices determine the presence of UserTag by polling, such as by periodically transmitting a discovery beacon signal that is triggered in response to signaling by UserTag (502). The I / O user device that receives the signaling indicates the presence report of UserTag to the IODH in the user terminal emulation server, along with the network address of the I / O user device (e.g., IP address, port number, MAC address, FQDN, etc.) (504). The user terminal emulation application corresponding to a specific user (i.e., UserTag) is updated in relation to the detected presence of the user (506).

[0073] The IODH can be made to receive notifications from I / O user devices that are in the vicinity of the UserTag. Further UI capability discovery (synchronization) communication takes place between the user terminal emulation server and the I / O user devices 510. The I / O user devices are associated with the user in the repository 120, along with the combinable UI capabilities provided by the corresponding join display and the set of I / O user devices in the vicinity of the UserTag. By operation 512, here, the user via the UserTag is made reachable within the system through a set of identified I / O user devices having identified UI capabilities (e.g., speaker yes / no, display yes / no, microphone yes / no, keyboard yes / no, etc.) within area 131, whereby it has been found that through it a logical virtualized user terminal can be created through which the user can be provided with communication services. The IODH further predicts, such as within a threshold time, which other I / O user devices will come to be placed in the vicinity of the user within area 132 and can have combinable UI capabilities that meet the capability requirements. The user can initiate communication services through the touch screen, voice commands sensed by the microphone, performing predefined gestures observable by the camera, and / or other inputs provided to one of the nearby I / O user devices.

[0074] In operation 514, a user with a UserTag triggers a call (e.g., a video call) using the UI of one of the I / O user devices, thereby triggering call signaling to the user terminal emulation server. In operation 518, the IODH queries the user (e.g., displays a message, makes a sound, etc.) through one of the I / O user devices proximate to the user and requests the user to select from among the available types of communication methods that can be used for the call at that time. One of the I / O user devices provides response signaling to the IODH indicating the communication method type selected by the user for the call. In operation 522, the user terminal emulation server conveys a call session stream request to network entity 150, which may include the identifier of the calling user, the identifier of the called user terminal, and the quality of service for the communication session. In operation 522, the user terminal emulation server receives a communication session acceptance (ACK) or communication session rejection (NACK) from network entity 150. If the communication session is rejected, the user terminal emulation server can attempt to renegotiate for the requested communication session with a degraded service, etc.

[0075] When a communication session is accepted (ACK), for each data type received as 528 as communication traffic from the requesting user terminal, based on the user terminal emulation server matching the characteristics of the data type to the UI capabilities specified by the repository for one of the I / O user devices, it selects one of the I / O user devices from among the set of I / O user devices, and then transfers the data of that data type to the network address of the selected device among the I / O user devices (530). The I / O user device that is the source of the data transmits a data stream to the user terminal emulation server 100 through one or more sessions 536 (532), and the user terminal emulation server combines the data streams into a combined data stream (538), and this combined data stream is transferred to the called user terminal via the network entity 150 (540).

[0076] The user terminal emulation server 100 continuously monitors the presence of I / O user devices (534), determines when one or more of the I / O user devices are no longer in proximity to the user, and can cause them to no longer be included as part of the combined UI provided during an ongoing communication session, and / or determines when one or more of the I / O user devices that are predicted to be approaching area 132 soon, for example, come into proximity to the user, and can cause them to be included as part of the combined UI provided during the ongoing communication session. The user terminal emulation server can replace the UI capabilities of another I / O user device, for example, an I / O user device within area 132 that is predicted to come into proximity to the user, in response to the previous member of the set no longer being in proximity, with the set being used by the user for the ongoing communication session. The user terminal emulation server 100 can dynamically generate an updated prediction of the likelihood that the user will come into proximity to or remain in proximity to various I / O user devices, and can dynamically update the DRX settings used for the various I / O user devices based on the updated prediction.

[0077] Predict user proximity and set DRX settings for I / O user devices for communication services

[0078] Figure 10 shows a combined flowchart of the operations and related data flows between UserTag, I / O user device 130, and user terminal emulation server 100 for predicting when a user comes into proximity to an I / O user device and, in response, setting the DRX settings of the I / O user device to receive downlink communication from the RAN related to the communication service for the user, according to some embodiments of the present disclosure.

[0079] Referring to FIG. 10, the first I / O user device (IOD#1) detects (1000) the UserTag transmitted by the user, and transmits (1002) to the user terminal emulation server 100 the IOD data that is obtained from the UserTag or determined based on detecting the characteristics of the UserTag. The IOD data can include a user identifier, user preferences regarding one or more types of communication services, and / or user mobility information (such as location, moving speed, moving direction, etc.). The user preferences indicated by the IOD data can include one or more of whether the user prefers to use headset audio or speaker audio, the user's speaker volume preference, whether the user prefers to use camera video when participating in an online meeting, the user's document language preference, the user's keyboard layout setting preference, the user's video characteristic preference (such as minimum text size priority), etc.

[0080] In the example of FIG. 10, the IOD data is received by the I / O user device handler (IODH) 212, and the IODH 212 associates (1004) the first I / O user device (IOD#1) with the user terminal emulation application 110, and transmits (1006) to the user terminal emulation application 110 a notification indicating that the first I / O user device (IOD#1) is then in proximity to the user and available for providing communication services to the user. The IODH 212 transmits (1008) a prediction request including at least a portion of the IOD data, such as the user identifier and an indication that the first I / O user device (IOD#1) is then in proximity to the user.

[0081] In some embodiments, the prediction request is provided to a proximity prediction and DRX configuration module 252, which uses a machine learning model 252 to predict (1010) (also 1102 in FIG. 11) the likelihood that the user will come into proximity with other I / O user devices, if any, based on the content of the received prediction request. In one embodiment, the machine learning model 252 determines one or more I / O user devices that meet a criterion for having a likelihood of meeting a threshold of coming within a threshold proximity range of the user within a threshold time. For any of the I / O user devices that meet the criterion, the module determines a DRX configuration based on the predicted likelihood that the user will come into proximity with the I / O user device (1104 in FIG. 11) and configures the I / O user device to use the DRX configuration to receive downlink wireless communication from the RAN 220 associated with the communication service (1106 in FIG. 11).

[0082] In one embodiment, predicting the likelihood that the user will come into proximity with an I / O user device (1010 in FIG. 10 and 1102 in FIG. 11) includes estimating the time until the user comes into proximity with the I / O user device. The DRX configuration is determined based on the estimated time (1104 in FIG. 11).

[0083] In another exemplary embodiment, module 250 predicts the likelihood that the user will come close to a first I / O user device based on an estimation that the user will come close to the first I / O user device within a first elapsed time (1010 in FIG. 10 and 1102 in FIG. 11). Similarly, module 250 predicts the likelihood that the user will come close to a second I / O user device based on an estimation that the user will come close to the second I / O user device within a second elapsed time that is longer than the first elapsed time (1010 in FIG. 10 and 1102 in FIG. 11). Similarly, module 250 predicts the likelihood that the user will come close to a third I / O user device based on an estimation that the user will come close to the third I / O user device within a third elapsed time that is longer than the second elapsed time (1102 in FIG. 11). Module 250 determines a first DRX setting for setting a first I / O user device based on the first elapsed time, a second DRX setting for setting a second I / O user device based on the second elapsed time, and a third DRX setting for setting a third I / O user device based on the third elapsed time (1104 in FIG. 11). The second DRX setting sets the second I / O user device such that the low power consumption mode time operates at a greater percentage compared to the high power consumption mode time as compared to the first I / O user device set by the first DRX setting. The third DRX setting sets the third I / O user device such that the low power consumption mode time operates at a greater percentage compared to the high power consumption mode time as compared to the second I / O user device set by the second DRX setting. During the low power consumption mode, the first, second, and third I / O user devices cannot receive downlink wireless communication from the RAN. In contrast, during the high power consumption mode, the first, second, and third I / O user devices can receive downlink wireless communication from the RAN.

[0084] In another related embodiment, the prediction of the likelihood that the user will come close to the I / O user device of module 250 (1010 in FIG. 10 and 1102 in FIG. 11) includes generating a set of proximity probability values indicating the likelihood that the user will come close to the I / O user device as a function of a set of different elapsed times. Then, the DRX setting is determined based on the set of proximity probability values (1104 in FIG. 11).

[0085] Determining the DRX setting of the I / O user device within the set can include determining a set of individual DRX settings for the individual I / O user devices within the set based on an individual operating characteristic of the I / O user device within the set. Then, the operation can set the I / O user devices within the set to use the DRX setting to receive downlink wireless communication from the RAN associated with the communication service, and the operation includes communicating, for an individual one of the I / O user devices within the set, one of the sets of DRX settings determined based on an individual characteristic of the individual I / O user device within the set to the individual I / O user device within the set.

[0086] When determining the DRX setting of the I / O user device within the set, the operation can identify the power-limited one of the I / O user devices within the set that is most restricted by the remaining operating time available from the battery power with respect to the other I / O user devices within the set. Next, the operation determines the DRX setting of the I / O user device within the set based on the operating characteristic of the power-limited one of the I / O user devices.

[0087] In another embodiment, the operation (1012 in FIG. 10 and 1104 in FIG. 11) for determining the DRX setting based on the predicted likelihood that the user will be in proximity to the I / O user device includes determining the DRX setting of the I / O user device based on information indicating at least one of the following operating characteristics of the I / O user device received from the I / O user device: downlink streaming audio playback capability, downlink streaming video display capability, uplink streaming microphone audio capability, and uplink streaming camera video capability.

[0088] In another embodiment, the operation (1012 in FIG. 10 and 1104 in FIG. 11) for determining the DRX setting of one or more I / O user devices includes sending a query message to the RAN 220 requesting identification of the current changeable DRX setting configured for the I / O user device, and then determining the DRX setting based on the content of the response message to the query message from the RAN and based on the predicted likelihood that the user will come into proximity to the I / O user device.

[0089] Module 252 provides a prediction response (1014) to IODH212 indicating that the second I / O user device (IOD#2) meets the criteria in the example of FIG. 10. The prediction response can identify a list of any I / O user devices that meet the determination by the machine learning model 252 and identify the determined DRX setting.

[0090] In the example of FIG. 10, IODH212 determines (1016) whether to associate the second I / O user device (IOD#2) with the user terminal emulation application 110 based on the predicted response and whether the second I / O user device (IOD#2) has an I / O user interface that meets the ability criteria for the user to use the communication service via the network entity 150. When IODH212 determines (1016) to associate the second I / O user device (IOD#2) with the user terminal emulation application 110, IODH212 can communicate the DRX settings and identification information of the second I / O user device (IOD#2) to the RAN 220, such as the serving eNB, or an intermediate network node that converts the DRX settings to the converted DRX settings provided to the RAN, in order to set the DRX operation of the second I / O user device (IOD#2) according to the determined DRX settings for more quickly receiving and using the downlink communication from the RAN 220 related to the communication service.

[0091] When communicating the DRX settings and identification information of the second I / O user device (IOD#2) to the RAN or an intermediate network node that converts the DRX settings to the converted DRX settings provided to the RAN in order to set the DRX operation of the second I / O user device (IOD#2), the operation can communicate to the RAN or the intermediate network node a pointer to a set of DRX settings in a preconfigured DRX settings repository within the RAN or preconfigured within the intermediate network node that is used to set the DRX operation of the identified second I / O user device (IOD#2).

[0092] The configuration of an I / O user device (e.g., a second I / O user device (IOD#2)) for using DRX settings to receive downlink wireless communication from a RAN related to a communication service (1018 in FIG. 10 and 1106 in FIG. 11) can include communicating the DRX settings to the second I / O user device (IOD#2) using radio resource control (RRC) signaling via the RAN.

[0093] IODH212 can further send a notification to the user terminal emulation application 110 indicating that the second I / O user device (IOD#2) is available or will soon be available for the user to provide a communication service (1020). In this way, the user terminal emulation application 110 can recognize that it can use the second I / O user device (IOD#2) to start a communication service with the user or perform a handoff of an ongoing communication service involving the user, such as switching from using the first I / O user device (IOD#1) to using the second I / O user device (IOD#2). For example, an audio and / or video stream that was being transferred to the first I / O user device (IOD#1) may be transferred to the second I / O user device (IOD#2) additionally or alternatively in response to, for example, the first I / O user device (IOD#1) stopping detecting the presence of the UserTag for at least a threshold time and / or in response to the second I / O user device (IOD#2) detecting a new presence of the UserTag.

[0094] Predicting the user's proximity to an I / O user device using a machine learning model

[0095] Here, various methods that can be used to train a machine learning model 252 and predict the user's proximity to one or more I / O user devices (1010 in FIG. 10 and 1102 in FIG. 11) will be described.

[0096] In some embodiments, the machine learning model 252 includes a decentralized federated learning architecture having a hierarchical association between the layers of the machine learning model. The layers of the local machine learning model are processed and trained to track information indicative of a user's habits regarding the use of communication services (e.g., as a function of various types of communication services, as a function of time and / or day of the week, as a function of the number of people participating in the communication service and / or a particular person, which I / O user device the user normally uses). When the local machine learning model is updated based on the observed user activity, the model parameters are also transmitted to a higher-level machine learning model that can exist within the IODH 212 trained with knowledge regarding the relative position of the I / O user device and the associated local machine learning model that more locally monitors the use of the I / O user device. Each model may be configured as a deep neural network (DNN) or a convolutional neural network (CNN).

[0097] The division of responsibility between the layers of the model hierarchy can be set according to geographical area constraints. For example, a "sub-IODH" can access process information regarding only a list of urban constraints on the location of I / O user devices and is trained based on the user usage of I / O user devices within that city. And that city-based model can be directly connected to a higher-level "municipality model" encompassing multiple cities or a "national model" encompassing multiple municipalities, and so on. The architectural layout of the hierarchical machine learning model may be manually set by one or more model owners and / or may be dynamically self-configured according to, for example, the number of users, the number of I / O user devices, the observed pattern of mobility between I / O user devices, etc. Cities, municipalities, etc. are non-limiting examples, and any grouping of I / O user devices for the machine learning model can be used. The grouping may be based on data rate (such as the number of I / O user devices communicating with the IODH 212), the number of users, and / or local / regional regulatory boundaries.

[0098] The association between the I / O user device and the individual models of the machine learning model may be remapped over time to reflect changes in the location of the I / O user device, such as when a portion of the I / O user device is not geographically fixed and is instead mobile.

[0099] The repository database 120 (e.g., FIG. 1) including the location and UI capabilities of the I / O user device can be organized into a data structure similar to a lookup table that is continuously updated at the new location of the I / O user device. Alternatively, an improved approach can use a network model database or a hierarchical model constructed by the IODH 212 when a new I / O user device is added. The search starts traversing from the data points around it (geographically) until the search criteria are met and then searches from there, whereby the repository database 120 is better able to handle multiple accesses simultaneously.

[0100] The machine learning model 252 can be trained based on the time series of I / O user devices that have been observed in the past to become sequentially closer to the user. For example, a first I / O user device near an entrance detects proximity to the user, then a second I / O user device further down the corridor detects proximity to some or all of those users, then a third I / O user device further down the corridor detects proximity to some or all of those users, and then a fourth I / O user device in the main conference room further down the corridor detects proximity to some or all of those users, and so on. In one embodiment, the operation (1008, 1102) of predicting the likelihood that an I / O user device will become closer to the user involves processing information indicating the user's current proximity to another I / O user device via the machine learning model 252 trained based on the time series of I / O user devices that have been observed in the past to become closer to the user, and predicting the likelihood that the I / O user device will become closer to the user based on the output of the machine learning model 252 by processing the information.

[0101] The DRX settings (1012 in FIG. 10 and 1104 in FIG. 11) determined for the I / O user device can be adjusted based on the output of the machine learning model 252 indicating the predicted likelihood that the user will become closer to the I / O user device. The operation can process information indicating the user's current proximity to another I / O user device via the machine learning model 252 trained based on the time series of I / O user devices identified in a repository that have been observed in the past to become closer to the user in order to output an indication probability that the user is likely to become closer to the I / O user device. Next, the operation adjusts the DRX settings set for the I / O user device based on the indication probability output by the machine learning model 252.

[0102] The machine learning model 252 can be trained based on historical observations of which users were proximate to which I / O user devices as a function of time and date. In one embodiment, the task of predicting the likelihood that an I / O user device will come into proximity with a user involves processing time and date (where "date" can be day of the week, day number, or month and day number) through a machine learning model 252 trained based on past observed proximity between a specified user and a specified I / O user device at a specified time and date to output a probability prediction of which of the specified users is predicted to come into proximity with the specified I / O user device. Next, the task predicts whether the I / O user device will come into proximity with the user based on the user's identification information and the probability prediction output by the machine learning model 252 (1012, 1016, 1104, 1108).

[0103] The machine learning model 252 may be trained based on the location of the I / O user device, such that the user's then-current location can, if available, generate a prediction of which I / O user devices are likely to be in proximity to the user. In one embodiment, the task of predicting the likelihood that an I / O user device will come into proximity with a user (1010 in FIG. 10 and 1102 in FIG. 11) involves processing the user's then-current location through a machine learning model 252 trained based on the location of the I / O user device. Next, the task predicts the likelihood that the user will come into proximity with the I / O user device based on the output of the machine learning model 252 by processing the user's then-current location.

[0104] The machine learning model 252 can be trained based on past observed I / O user devices selected for use by users who were in proximity to the next location while using a communication service. FIG. 12 is a flowchart of corresponding operations that can be performed by a proximity prediction and DRX setting module 250 according to one embodiment.

[0105] Referring to FIG. 12, the operation processes (1200) the predicted next location of the user via a machine learning model 252 trained based on past observed I / O user devices selected for use by a user who was in proximity to the following location while using the communication service, and outputs a set of I / O user devices at the next location that can be used by the user for the communication service. The operation determines (1202) the DRX settings (also 1012 in FIG. 10 and 1104 in FIG. 11) of the I / O user devices in the set. Then, the operation configures (1204) the I / O user devices in the set to use the DRX settings for receiving downlink wireless communication from the RAN associated with the communication service.

[0106] The DRX settings of the I / O user devices in the set can be determined for each of the I / O user devices based on their respective operating characteristics. For example, I / O user devices with different operating characteristics can correspondingly have different sets of determined DRX settings. The operation 1202 of determining the DRX settings of the I / O user devices in the set can include determining a set of one DRX setting for each of the I / O user devices in the set based on one operating characteristic of each of the I / O user devices in the set. The operation 1204 of configuring the I / O user devices in the set to use the DRX settings for receiving downlink wireless communication from the RAN associated with the communication service can include communicating, for each of the I / O user devices in the set, one set of DRX settings determined based on one characteristic of each of the I / O user devices in the set for each of the I / O user devices in the set.

[0107] In another embodiment, operation 1202 of determining the DRX setting of the I / O user devices in the set involves identifying the one power-limited I / O user device in the set that is most restricted by the remaining operating time available from the battery power, for the other I / O user devices in the set. Next, the operation of determining the DRX setting of the I / O user devices in the set is based on the operating characteristics of the one power-limited I / O user device among the I / O user devices.

[0108] In some embodiments, the input data is processed via a machine learning model 252 that returns a set of I / O user devices that are predicted to come within proximity of one or more users at a defined frequency. Enhanced training of the machine learning model 252 over time can include using feedback indicating which of the I / O user devices enumerated in the set were and / or were not selected by the IODH 212 and / or the user as an interface for one or more communication services. The machine learning model parameters updated by the training can be provided to one or more upper-level machine learning models (e.g., a small geographical area layer of the machine learning model, a connected upper layer of the machine learning model for a larger geographical area, etc.) within the hierarchical set of machine learning models as described above.

[0109] Exemplary DRX settings that can be set for the I / O user devices are described in further detail below.

[0110] As an extension to the 3GPP LTE standard, the RAN 220 can set the DRX setting of the I / O user device regarding when to sleep and when to wake up. The DRX setting can be set via an RRC (Radio Resource Control) message such as RRC ConnectionReconfiguration or RRC connection establishment. The DRX setting can be transmitted under the DRX-config structure under MAC-MainConfig. TIFF0007695415000001.tif118170TIFF0007695415000002.tif71170The range of parameters used is shown below. TIFF0007695415000003.tif180170TIFF0007695415000004.tif76170

[0111] In addition to the above timer, the eNB MAC can also control I / O user device DRX by using a DRX command as a MAC control element.

[0112] The I / O user device can notify the RAN220 about the DRX support possibility that the RAN220 can enable or disable based on the I / O user device capabilities and network operator requirements. The I / O user device DRX support can be communicated from the I / O user device to the RAN220 (and from there to the user terminal emulation server 100) via a functional information message as shown below. TIFF0007695415000005.tif128170TIFF0007695415000006.tif73170

[0113] The MAC entity can be set by the RRC having a DRX function that controls the PDCCH monitoring activity of the I / O user device for the C-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, semi-persistent scheduling C-RNTI (if set), UL semi-persistent scheduling V-RNTI (if set), eIMTA-RNTI (if set), SL-RNTI (if set), SL-V-RNTI (if set), CC-RNTI (if set), SRS-TPC-RNTI (if set), and AUL C-RNTI (if set) of the MAC entity.

[0114] In the case of RRC_CONNECTED, if DRX is configured, the MAC entity can discontinuously monitor the PDCCH using the DRX operations specified in this section; otherwise, the MAC entity continuously monitors the PDCCH.

[0115] When using DRX operations, the MAC entity shall also monitor the PDCCH in accordance with the requirements found in other sections of this specification.

[0116] RRC controls the DRX operations by setting the values of the timers onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimer (one for each DL HARQ process except for broadcast processes, for HARQ processes scheduled using 1 ms TTIs), drx-RetransmissionTimerShortTTI (one for each DL HARQ process, for HARQ processes scheduled using short TTIs), drx-ULRetransmissionTimer (one for each asynchronous UL HARQ process, for HARQ processes scheduled using 1 ms TTIs), drx-ULRetransmissionTimerShortTTI (one for each asynchronous UL HARQ process, for HARQ processes scheduled using short TTIs), longDRX-Cycle, drxStartOffset, and optionally drxShortCycleTimer and shortDRX-Cycle. HARQ RTT timers for each DL HARQ process (except for broadcast processes) and UL HARQ RTT timers for each asynchronous UL HARQ process are also defined.

[0117] The MAC entity can be configured by the RRC with a DRX function that controls the UE's PDCCH monitoring activity for the MAC entity's C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, and AI-RNTI.

[0118] When using DRX operation, the MAC entity shall also monitor the PDCCH according to the requirements found in other sections of this specification.

[0119] In the case of RRC_CONNECTED, if DRX is configured, for all activated serving cells, the MAC entity can discontinuously monitor the PDCCH using the DRX operation specified in this section; otherwise, the MAC entity shall monitor the PDCCH as specified in TS38.213.

[0120] The RRC controls the DRX operation by configuring the following parameters: - drx-onDurationTimer: The duration at the start of a DRX cycle, - drx-SlotOffset: The delay before starting drx-onDurationTimer, - drx-InactivityTimer: The duration after a PDCCH opportunity indicating a new UL or DL transmission for the MAC entity, - drx-RetransmissionTimerDL (per DL HARQ process excluding broadcast processes): The maximum duration until a DL retransmission is received, - drx-RetransmissionTimerUL (per UL HARQ process): The maximum duration until a grant for a UL retransmission is received, -drx-LongCycleStartOffset: The long DRX cycle and drx-StartOffset that defines the subframe at which the long DRX cycle and the short DRX cycle start, -drx-ShortCycle (optional): The short DRX cycle, -drx-ShortCycleTimer (optional): The period for which the UE should follow the short DRX cycle, -drx-HARQ-RTT-TimerDL (for each DL HARQ process except the broadcast process): The minimum period before the DL assignment for HARQ retransmission is expected by the MAC entity, -drx-HARQ-RTT-TimerUL (for each UL HARQ process): The minimum period before the UL HARQ retransmission grant is expected by the MAC entity, -ps-Wakeup (optional): The setting for starting the drx-onDurationTimer related when the DCP is being monitored but not detected, -ps-TransmitOtherPeriodicCSI (optional): The setting for reporting periodic CSI other than L1-RSRP on the PUCCH during the period indicated by the drx-onDurationTimer when the DCP is set but the related drx-onDurationTimer has not been started, -ps-TransmitPeriodicL1-RSRP (optional): The setting for transmitting periodic CSI that is L1-RSRP on the PUCCH during the period indicated by the drx-onDurationTimer when the DCP is set but the related drx-onDurationTimer has not been started.

[0121] In some embodiments, the operation 1106 of configuring the I / O user device to use the DRX configuration to receive downlink wireless communication from the RAN related to the communication service includes configuring at least one of the following parameters used by the I / O user device for DRX operations based on the DRX configuration: - The period drx-onDurationTimer at the start of the DRX cycle, - The delay drx-SlotOffset before starting drx-onDurationTimer, - The period drx-InactivityTimer after a PDCCH opportunity indicating a new uplink or downlink transmission for the I / O user device, - The maximum period drx-RetransmissionTimerDL until a downlink retransmission is received by the I / O user device, - The maximum period drx-RetransmissionTimerUL until a grant for uplink retransmission is received by the I / O user device, - The subframe drx-LongCycleStartOffset at which the long DRX cycle starts, - The short DRX cycle drx-ShortCycle, - The period drx-ShortCycleTimer during which the I / O user device follows the short DRX cycle, - The minimum period drx-HARQ-RTT-TimerDL before a downlink assignment for hybrid automatic repeat request (HARQ) retransmission is expected by the I / O user device, and - The minimum period drx-HARQ-RTT-TimerUL before an uplink HARQ retransmission grant is expected by the I / O user device.

[0122] DRX configuration example based on proximity characteristics -

[0123] In a scenario where a user terminal emulation server 100, for example, a module 250 that uses a machine learning model 252, identifies an individual I / O user device or a cluster of frequently used I / O user devices, the server 100 can determine that there is a possibility that the user interaction with the I / O user device may decrease when the I / O user device enters the sleep mode excessively (frequently and / or for an excessive period). In some embodiments, an I / O user device that is predicted to be likely to be "next" close to the user, for example, having a higher probability, can be set with a shorter DTX cycle so as to be more responsive to any inbound data (i.e., wake up at a higher period to listen for paging information from the serving eNB).

[0124] The corresponding set of "frequently used IOD" DRX parameters can be characterized as follows: - Time until DRX becomes active: 200 ms - DRX cycle time short: 40 ms - DRX cycle time long: 80 ms - On period: 10 ms - Time alignment: INF - Time to idle: NaN

[0125] After 200 ms, the I / O user device enters DRX and must listen for any incoming downlink allocation (from the user terminal emulation server 100 or the serving eNB in response to communication) every 10 ms during each cycle. During the time alignment, the I / O user device must continue to send its status and measurement information to the serving eNB. This long time alignment often consumes the power and battery of the I / O user device and burdens the radio interface.

[0126] In related scenarios where individual I / O user devices or clusters of I / O user devices of the I / O user device are determined to not be used more frequently, another "less frequently used IOD" DRX setting that enables the I / O user device to return to sleep more quickly can be set and characterized as follows: - Time until DRX becomes active: 100 ms - DRX cycle time short: 40 ms - DRX cycle time long: 320 ms - On period: 10 ms - Time alignment: 1.92 s - Time to idle: 30 s

[0127] With a 100 ms DRX input time, an I / O user device with this DRX setting enters DRX faster than in the "frequently used IOD" scenario. Due to the significantly short 1.92 s time alignment requirement, the I / O user device does not need to continue sending their status and measurement information to the serving eNB as long as they were previously set, and after 30 s without data transmission, the network enables the I / O user device to enter the sleep state. In 5G operations, this can include a change in the RRC state from RRC_CONNECTED to RRC_IDLE and thus potentially removing the radio air interface connection.

[0128] Apart from the above exemplary DRX parameters (also called settings), the user terminal emulation server 100 and the eNB can select and determine the use of other parameters that provide the desired DRX characteristics (e.g., "frequently wakes up" or "fast to deep sleep") for the selected I / O user device.

[0129] Further operations of the user terminal emulation server 100 according to some other embodiments are described below.

[0130] The User Equipment Emulation Server 100 can itself determine when to configure I / O user devices with a new DRX configuration in order to provide improved performance based on the predicted I / O user device clustering and mobility characteristics determined from the media service characteristics of, for example, one I / O user device or a group of I / O user devices in relation to some service threshold. The exchange of DRX configurations can be done in different ways, for example, as follows: 1) The User Equipment Emulation Server 100 directly provides the DRX configuration to the RAN 220 (e.g., eNB, gNB) serving one or more I / O user devices to be configured. The RAN 220 updates the connection with the I / O user devices and configures DRX with these settings; or 2) The User Equipment Emulation Server 100 recognizes a set of DRX parameters. The RAN 220 (e.g., eNB, gNB) is pre-configured with a similar list. The User Equipment Emulation Server 100 provides a pointer to one of the sets of DRX configurations in the list to notify the RAN 220 which DRX parameter set should be used to configure one or more I / O user devices. The I / O user device (e.g., UE) assistance message can include a pointer to the set in the list so that the RAN 220 selects the correct set of DRX configurations.

[0131] In a further embodiment, the User Equipment Emulation Server 100 can also provide a set of RRC state transition parameters determined by the User Equipment Emulation Server 100 corresponding to the clustering characteristics and usage patterns of the I / O user devices to the RAN 220 (e.g., eNB, gNB) serving one or more I / O user devices. This information can be carried in an RRC protocol message or via an application coordination channel through some RANs.

[0132] In a further embodiment, the user terminal emulation server 100 can also send a message to the I / O user device to put the I / O user device in the active RRC state or to prevent the I / O user device from entering a less active RRC state such as RRC idle or RRC inactive. The message generation interval and size may also be used based on information obtained from the I / O user device (UE) or the mobile network, such as the CN, via the AF.

[0133] As described above, in a 3GPP LTE mobile network, the RRC protocol can be used to notify the UE about DRX settings and initiate the UE to transition between RRC states, or the transition can be implicitly performed by timer settings. The RRC protocol resides in the RAN220, such as an eNB or gNB.

[0134] The user terminal emulation server 100 notifies the network about the appropriate DRX settings and / or RRC settings for the I / O user device (UE). The user terminal emulation server 100 can communicate this information directly towards the OAM system interface, or via the CN application interface, or further via the RAN interface.

[0135] Via the CN, the user terminal emulation server 100 interfaces with an application function (AF) that further incorporates the information into the functions of the CN. The AF converts the information received from the user terminal emulation server 100, if necessary, into something that the CN can understand, and that CN is trickled down to the RAN, for example via the PCRF and AMF, or via the RAN OAM, to update the settings of those specific I / O user devices that are the subject of the information received by the AF, such as DRX. The trickle-down may include changing the bearers used by the RAN towards the I / O user device (UE) or updating the bearer part of the UE context.

[0136] Similarly, the user terminal emulation server 100 may be connected to the OAM of the network through an interface. Then, the OAM of the RAN updates the settings of the I / O user device (UE) through internal functions.

[0137] The information transmitted by the user terminal emulation server 100 to the network via OAM or AF, or directly to the RAN, may be converted into corresponding (DRX) settings by the network, or may be the actual DRX settings.

[0138] An exemplary operation for signaling DRX settings will be described below.

[0139] Proximity prediction for DRX setting conversion -

[0140] In one embodiment, the user terminal emulation server 100 uses the 3GPP RRC protocol to communicate with the RAN. The user terminal emulation server 100 determines that DRX settings should be set for a group of I / O user devices. The user terminal emulation server 100 divides the group of I / O user devices into, for example, the following three subgroups: · 1 "Next" (where the usertag moves next) · 2 "Shortly" (which may be used after "Next") · 3 "Later" (estimated / judged to occur after / below "Shortly"))

[0141] The user terminal emulation server 100 generates a set of DRX settings for subgroup 1 "Next", for example, as follows. · onDurationTimer psf_i1 · drx-InactivityTimer psf_i2 · drx-RetransmissionTimer psf_i3 ·longDRX-CycleStartOffset sf_i1 ·shortDRX SEQUENCE{shortDRX-Cycle sf_i2} ·drxShortCycleTimer sf_i3

[0142] The user terminal emulation server 100 generates a set of DRX settings as follows, for example, for subgroup 2 "soon". ·onDurationTimer psf_j1 ·drx-InactivityTimer psf_j2 ·drx-RetransmissionTimer psf_j3 ·longDRX-CycleStartOffset sf_j1 ·shortDRX SEQUENCE {shortDRX-Cycle sf_j2} ·drxShortCycleTimer sf_j3

[0143] In another embodiment, the user terminal emulation server 100 does not use the 3GPP RRC protocol when communicating with the RAN. The user terminal emulation server 100 divides the group of I / O user devices into, for example, the following three "activity characteristic subgroups": ·1 "next" (where the usertag moves next) o "time and response metric requirements" #1 ·2 "soon" (which may be used after "next") o "time and response metric requirements" #2 ·3 "later" (presumed / judged to occur after / below "soon") o "time and response metric requirements" #3

[0144] The user terminal emulation server 100 provides the attributes of the activity characteristic group to a receiving (CN) node in the telecommunications network, such as an application function (AF).

[0145] Next, the proximity prediction-based IODRRCConnectionReconfiguration will be described.

[0146] Information on the "time and response metric requirements" of each "activity characteristic subgroup" for each IOD ("I / O user device") subgroup identifier may be provided (transmitted) to the CN. The CN can convert, for example, the "time and response metric requirement" #1 into DRX-related parameters as follows. ·onDurationTimer psf_i1 ·drx-InactivityTimer psf_i2 ·drx-RetransmissionTimer psf_i3 ·longDRX-CycleStartOffset sf_i1 ·shortDRX SEQUENCE{shortDRX-Cycle sf_i2} ·drxShortCycleTimer sf_i3

[0147] Alternatively, the user terminal emulation server 100 can convert the "activity characteristic subgroup" into a set of DRX settings that can be transmitted to the CN as a valid RANIODrrcConnectionReconfiguration request for each I / O user device group identifier. ·Put <message name> into the MicoServiceRRCConnectionReconfiguration message. ·Look up the I / O user device group identifier in the TIMSI / IMSI / UE identification information. ·Forward the message to the eNB / gNB to nodes X... and MME... ·The eNB / gNB receives the MicoServiceRRCConnectionReconfiguration message. Check the validity of the o-parameter range (which may be achieved in the step before the CN microservice reception step). o Accept the application to the upper layer (or NACK with a cause value). · The I / O user device receives the upper layer provided parameter settings, o Apply from the upper layer provided parameter settings, · The upper layer receives the MicoServiceRRCConnectionReconfiguration response from the serving eNB / gNB, o Forward it to the CN AF, · The CN AF responds to the user terminal emulation server 100 with RANIODrrcConnectionReconfiguration complete / reject o With a cause value if applicable.

[0148] Next, possible further useful information exchange will be described.

[0149] The user terminal emulation server 100 sends an I / O user device RAN capability request to the CN / OAM. The CN / OAM responds with, for example, the following list: · I / O user device DRX settings o I / O user device group identifier o <Format> or <Format><value range> · I / O user device power settings (which may be useful for understanding how the I / O user device clusters are associated) o I / O user device group identifier o <Format> or <Format><value range>

[0150] Signaling messages from the user terminal emulation server 100 to the base station (eNB / gNB), and / or end points in the EPC / 5GC such as the following messages: The user terminal emulation server 100 requests an updated DRX setting of the I / O user device to the radio base station (eNB, gNB) via the CN.

[0151] In this embodiment, the user terminal emulation server 100 cooperates with the proximity clustering ML model management server, and provides a request to the MME / serving eNB that the selected I / O user device can be a target of the updated DRX setting according to the user terminal emulation server 100 / ML model-based clustering determination.

[0152] The network, such as AF or OAM (or other related nodes), receives the DRX_message and determines the serving base station of each device in the cluster of I / O user devices based on the selected I / O user device. Further conversion of the IDOH message into an instruction / format that can be understood by the RAN may be required. However, when receiving the information in the DRX message from the user terminal emulation server 100, the serving base station can · convert the user terminal emulation server 100 message information into an RRCReconfigurationRequest message, · select DRX-Config parameters corresponding to the intent of the received DRX_message, o that is, corresponding to "stay awake" or "go to sleep", etc., and · send the updated DRX setting to the selected I / O user device in the RRCReconfigurationRequest message.

[0153] Here, the operation for the user terminal emulation server 100 to construct the RRCReconfigurationRequest message passed to the eNB via the CN will be described.

[0154] The user terminal emulation server 100 itself can compile an RRCReconfigurationRequest message with relevant DRX parameter settings selected according to the determined intent of the I / O user device activity, and then send the message to the network. Therefore, the network does not need any conversion of the message information but can pass it to the serving RAN (e.g., eNB or gNB) of the I / O user device. A new or additional message header may be required to indicate the use of the compiled pass-through downward message of the user terminal emulation server 100.

[0155] The DRX reconfiguration response of the I / O user device according to some embodiments can include that after the I / O user device executes all the transmitted commands, the I / O user device responds to the serving RAN (e.g., eNB or gNB) with an RRCConnectionReconfigurationComplete message.

[0156] Cloud implementation

[0157] Some or all of the above operations, as performed by the user terminal emulation server 100 or the I / O user device 130, may instead be performed by other nodes and / or by another node that is part of the cloud computing resources. For example, those operations may be performed as a network function close to the edge, e.g., in CloudRAN or the core network, in a cloud server or cloud resources of a telecommunications network operator, and / or by a cloud server or cloud resources of a media provider, e.g., an iTunes service provider or a Spotify service provider.

[0158] Examples of I / O user devices and user terminal emulation servers

[0159] FIG. 8 is a block diagram of components of an I / O user device 130 configured to operate according to some embodiments. The I / O user device 130 may include a wired / wireless network interface circuit 902, a short-range communication circuit 920, at least one processor circuit 900 (processor), and at least one memory circuit 910 (memory). The processor 900 is connected to communicate with other components. The memory 910 stores program code 912 that is executed by the processor 900 to perform the operations disclosed herein. The processor 900 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors) that may be collocated or distributed across one or more data networks. The processor 900 is configured to execute the program code 912 in the memory 910, described hereinbelow as a computer-readable medium, to perform some or all of the operations and / or methods of one or more of the embodiments disclosed herein for a mobile electronic device. The I / O user device 130 may include one or more UI devices including, but not limited to, a microphone 940, a speaker 950, a camera 930, a display device 960, and a user input interface 970.

[0160] FIG. 9 is a block diagram of components of a user terminal emulation server 100 configured to operate according to some embodiments. The user terminal emulation server 100 may include a wired / wireless network interface circuit 1020, a repository 120 (e.g., an enumerated I / O user device, UI capabilities of the I / O user device, known proximity to user identification information, etc.), a display device 1030, a user input interface 1040 (e.g., a keyboard or touch-sensitive display), at least one processor circuit 1000 (processor), and at least one memory circuit 1010 (memory). The processor 1000 is connected to communicate with the other components. The memory 1010 stores a user terminal emulation application 1012 to be executed by the processor 1000 to perform the operations described in this disclosure. The memory 1010 also stores a configuration module 250 for proximity prediction and DRX setting. In some embodiments, the module 250 includes a machine learning model 252. The processor 1000 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors) that may be collocated or distributed across one or more data networks. The processor 1000 is configured to execute computer program instructions within the memory 1010, described hereinafter as a computer-readable medium, to perform some or all of the operations and / or methods of one or more of the embodiments disclosed herein for a mobile electronic device.

[0161] Abbreviations 3GPP 3rd Generation Partnership Project 5GC 5G Core AF Application Function AMF Access and Mobility Management Function App Application, i.e., program CN Core Network CNN Convolutional Neural Network DNN Deep Neural Network DRX Discontinuous Reception eNB evolved Node B (commonly known as RBS, Radio Base Station) EPC Evolved Packet Core gNB eNB for 5G GNSS Global Navigation Satellite System GPS Global Positioning System GW Gateway HARQ Hybrid Automatic Repeat reQuest HO Handover ICMP Internet Control Message Protocol IOD Input / Output User Device IODH Handler for Input / Output Devices ITU International Telecommunication Union MME Mobility Management Entity RAN Radio Access Network RFID Radio Frequency Identification RRC Radio Resource Control RTP Real-time Transport Protocol RTCP Real-time Control Protocol NTP Network Time Protocol SDP Session Description Protocol SR Sender Response TTI Transmission Time Interval UE User Equipment

[0162] Further Definitions and Embodiments

[0163] In the foregoing description of various embodiments of the inventive concept, it should be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the inventive concept pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning that coincides with their meaning in the context of the present specification and the related art, and should not be interpreted in an idealized or overly formal sense as defined herein.

[0164] When an element is referred to as being "connected to", "coupled to", "responsive to", or variations thereof, another element, that element can be directly connected to, coupled to, or responsive to the other element, or intervening elements may be present. In contrast, when an element is referred to as being "directly connected to", "directly coupled to", "directly responsive to", or variations thereof, another element, no intervening elements are present. Like numbers refer to like elements throughout. Further, as used herein, "coupled to", "connected to", "responsive to", or variations thereof may include being wirelessly coupled to, wirelessly connected to, or wirelessly responsive to. As used herein, the singular forms "a", "an", and "the" shall include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and / or clarity. The term "and / or" includes any and all combinations of one or more of the corresponding listed terms.

[0165] To describe various elements / operations, terms such as first, second, third, etc. may be used in this specification, but it should be understood that these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another. Thus, without departing from the teachings of the present inventive concept, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments. The same reference number or the same reference sign indicates the same or similar elements throughout this specification.

[0166] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variations thereof are open-ended and include one or more of the recited features, integers, elements, steps, components, or functions, but do not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions, or groups thereof. Further, the common abbreviation "e.g.", which is derived from the Latin phrase "exempli gratia", may be used to introduce or specifically list one or more general examples of the foregoing items and is not limiting of such items. The common abbreviation "i.e.", which is derived from the Latin phrase "id est", may be used to specifically list a particular item from a more general statement.

[0167] Exemplary embodiments are described herein with reference to block diagrams and / or flowchart diagrams of a computer-implemented method, apparatus (system and / or device) and / or computer program product. It should be understood that the blocks of the block diagrams and / or flowchart diagrams, as well as combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by computer program instructions executed by one or more computer circuits. These computer program instructions can be provided to a processor circuit of a general-purpose computer circuit, a special-purpose computer circuit, and / or other programmable data processing circuits to create a machine, whereby the instructions executed via the processor of the computer and / or other programmable data processing device implement the functions / acts specified in one or more blocks of the block diagram and / or flowchart, and thereby, to convert and control transistors, values stored in memory locations, and other hardware components within such circuits to create means (functions) and / or structures for implementing the functions / acts specified in the blocks of the block diagram and / or flowchart.

[0168] These computer program instructions can also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing device to function in a particular manner, whereby the instructions stored in the computer-readable medium create a manufacture including instructions for implementing the functions / acts specified in one or more blocks of the block diagram and / or flowchart. Accordingly, embodiments of the inventive concept may be embodied in hardware and / or in software (including firmware, resident software, microcode, etc.) running on a processor such as a digital signal processor, which may sometimes be generically referred to as a "circuit", "module", or a variation thereof.

[0169] Also, in some alternative implementations, it should be noted that the functions / acts recited in a block may occur in an order other than that recited in a flowchart. For example, depending on the functionality / acts involved, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Further, the functionality of a given block of a flowchart and / or block diagram may be separated into multiple blocks, and / or the functionality of two or more blocks of a flowchart and / or block diagram may be at least partially integrated. Finally, other blocks may be added / inserted between the blocks illustrated, and / or blocks / acts may be omitted without departing from the scope of the inventive concept. Additionally, some of the figures include arrows on communication paths to indicate a primary direction of communication, but it should be understood that communication may occur in a direction opposite to that shown by the illustrated arrows.

[0170] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the inventive concept. All such variations and modifications are intended to be included herein within the scope of the inventive concept. Accordingly, the above-disclosed subject matter should be regarded as illustrative and not restrictive, and the appended examples of embodiments are intended to encompass all such modifications, extensions, and other embodiments that fall within the spirit and scope of the inventive concept. Thereby, to the maximum extent permitted by law, the scope of the inventive concept should be determined by the broadest permissible interpretation of this disclosure, including the following examples of embodiments and their equivalents, and should not be limited or restricted by the forms for carrying out the above invention.

Claims

1. A user terminal emulation server (100) for providing a communication service to a user via one or more input and / or output (I / O) user devices, registering user information with a network entity (150) that provides the communication service, predicting the likelihood that the user will come close to the I / O user device, determining a discontinuous reception (DRX) setting based on the predicted likelihood that the user will come close to the I / O user device, and setting the I / O user device to use the DRX setting to receive downlink wireless communication from a radio access network (RAN) related to the communication service The user terminal emulation server (100) is configured as described above.

2. The prediction of the likelihood that the user will come close to the I / O user device includes estimating the time until the user comes close to the I / O user device, and The DRX setting is determined based on the estimated time. The user terminal emulation server (100) according to claim 1.

3. Predicting the likelihood that the user will come close to the first I / O user device based on the presumption that the user will come close to the first I / O user device within a first elapsed time, Predicting the likelihood that the user will come close to the second I / O user device based on the presumption that the user will come close to the second I / O user device within a second elapsed time longer than the first elapsed time, Predicting the likelihood that the user will come close to the third I / O user device based on the presumption that the user will come close to the third I / O user device within a third elapsed time longer than the second elapsed time, Determine a first DRX setting for setting the first I / O user device based on the first elapsed time, determine a second DRX setting for setting the second I / O user device based on the second elapsed time, and set the second I / O user device such that, compared with the first I / O user device set by the first DRX setting, the low power consumption mode time operates at a larger ratio than the high power consumption mode time, and determine a third DRX setting for setting the third I / O user device based on the third elapsed time, and set the third I / O user device such that, compared with the second I / O user device set by the second DRX setting, the low power consumption mode time operates at a larger ratio than the high power consumption mode time. During the low power consumption mode, the first, second, and third I / O user devices cannot receive downlink wireless communication from the RAN, and during the high power consumption mode, the first, second, and third I / O user devices can receive downlink wireless communication from the RAN, The user terminal emulation server (100) according to claim 2, further configured as described above.

4. The prediction of the likelihood that the user will come close to the I / O user device includes generating a set of proximity probability values indicating the likelihood that the user will come close to the I / O user device as a function of a set of different elapsed times, and the DRX setting is determined based on the set of proximity probability values. The user terminal emulation server (100) according to any one of claims 1 to 3.

5. for predicting the likelihood that the user will come close to the I / O user device, Process information indicating the user's proximity at that time to another I / O user device via a machine learning model (252) trained based on the time series of I / O user devices that have been observed in the past to come close to the user, and Predict the likelihood that the I / O user device will come close to the user based on the output of the machine learning model (252) by processing the information. The user terminal emulation server (100) according to any one of claims 1 to 4, which is set as described above.

6. To predict the likelihood that the user will come close to the I / O user device, Process the user's position at that time via a machine learning model (252) trained based on the position of the I / O user device, and Predict the likelihood that the user will come close to the I / O user device based on the output of the machine learning model (252) by processing the user's position at that time. The user terminal emulation server (100) according to any one of claims 1 to 5, which is set as described above.

7. Process the predicted next position of the user via a machine learning model (252) trained based on past observed I / O user devices selected for use by a user who was close to the next position while using the communication service, and output a set of the I / O user devices at the next position that can be used by the user to use the communication service, Determine the DRX settings of the I / O user devices in the set, and Set the I / O user devices in the set so as to use the DRX settings to receive the downlink wireless communication from the RAN related to the communication service. The user terminal emulation server (100) according to any one of claims 1 to 6, which is further set as described above.

8. the determination of the DRX setting of the I / O user device in the set is based on an operation characteristic of one individual I / O user device in the set, determining a set of DRX settings for the one individual I / O user device in the set and for using the DRX setting to receive the downlink wireless communication from the RAN related to the communication service, the setting of the I / O user device in the set is for one individual I / O user device in the set, communicating with the one individual I / O user device in the set by using one of the set of DRX settings, which is determined based on the characteristic of the one individual I / O user device in the set The user terminal emulation server (100) according to claim 7, comprising.

9. the determination of the DRX setting of the I / O user device in the set is identifying one power-limited I / O user device in the set, which is most restricted by the remaining operating time obtainable from the battery power, compared with other I / O user devices in the set of I / O user devices in the set; determining the DRX setting for the I / O user device in the set based on the operation characteristic of the one power-limited I / O user device among the I / O user devices The user terminal emulation server (100) according to claim 7, comprising.

10. the setting of the I / O user device for using the DRX setting to receive the downlink wireless communication from the radio access network is To configure the DRX operation of the I / O user device, communicate the DRX configuration and identification information of the I / O user device to the RAN, or to an intermediate network node that converts the DRX configuration into a converted DRX configuration provided to the RAN The user terminal emulation server (100) according to any one of claims 1 to 9, including **Claim 11** To configure the DRX operation of the I / O user device, the communication of the DRX configuration and identification information of the I / O user device to the RAN, or to the intermediate network node that converts the DRX configuration into a converted DRX configuration provided to the RAN is Communicate to the RAN or the intermediate network node a pointer that references a set of DRX configurations in a repository of DRX configurations pre-set in the RAN or pre-set in the intermediate network node, which is used to configure the DRX operation of the identified I / O user device The user terminal emulation server (100) according to claim 10, including **Claim 12** The configuration of the I / O user device for using the DRX configuration to receive downlink wireless communication from the radio access network is Communicate the DRX configuration to the I / O user device using radio resource control (RRC) signaling via the RAN The user terminal emulation server (100) according to any one of claims 1 to 11, including **Claim 13** Determine the DRX configuration of the I / O user device based on information indicating at least one of the following operating characteristics of the I / O user device received from the I / O user device: downlink streaming audio playback ability, downlink streaming video display ability, uplink streaming microphone audio ability, and uplink streaming camera video ability The user terminal emulation server (100) according to any one of claims 1 to 12, which is further set as described above.

14. The setting of the I / O user device for using the DRX setting to receive downlink wireless communication from the RAN is Based on the DRX setting, the following parameters used by the I / O user device for the DRX operation: The period drx-onDurationTimer at the start of the DRX cycle, The delay drx-SlotOffset before starting the drx-onDurationTimer, The period drx-InactivityTimer after a PDCH indicates a new uplink or downlink transmission opportunity for the I / O user device, The maximum period drx-TransmissionTimerDL until a downlink retransmission is received by the I / O user device, The maximum period drx-TransmissionTimerUL until a grant for uplink retransmission is received by the I / O user device, The subframe drx-LongCycleStartOffset at which the long DRX cycle starts, The short DRX cycle drx-ShortCycle, The period drx-ShortCycleTimer during which the I / O user device follows the short DRX cycle, The minimum period drx-HARQ-RTT-TimerDL before a downlink allocation for hybrid automatic repeat request (HARQ) retransmission is expected by the I / O user device, and The minimum period drx-HARQ-RTT-TimerUL before an uplink HARQ retransmission grant is expected by the I / O user device The user terminal emulation server (100) according to any one of claims 1 to 12, including setting at least one of the above.

15. To determine the DRX setting based on the predicted likelihood that the user will come close to the I / O user device, send an inquiry message to the RAN requesting identification information of the current modifiable DRX setting configured for the I / O user device, and determine the DRX setting based on the content of the response message to the inquiry message from the RAN and based on the predicted likelihood that the user will come close to the I / O user device The user terminal emulation server (100) according to any one of claims 1 to 14, which is set as described above.

16. A method of a user terminal emulation server for providing a communication service to a user via one or more input and / or output (I / O) user devices, comprising: registering user information with a network entity providing the communication service (1100); predicting the likelihood that the user will come close to the I / O user device (1102); determining a discontinuous reception (DRX) setting based on the predicted likelihood that the user will come close to the I / O user device (1104); setting the I / O user device to use the DRX setting to receive downlink wireless communication from a radio access network (RAN) associated with the communication service (1106) and a method.

17. A non-transitory computer-readable medium storing program instructions executable by at least one processor of a user terminal emulation server for performing operations for providing a communication service to a user via one or more input and / or output (I / O) user devices, the operations comprising: Registering user information with a network entity that provides the communication service; Predicting the likelihood that the user will come close to the I / O user device; Determining a discontinuous reception (DRX) setting based on the predicted likelihood that the user will come close to the I / O user device; Configuring the I / O user device to use the DRX setting to receive downlink wireless communication from a radio access network (RAN) associated with the communication service; A non-transitory computer-readable medium including the above.

Images