User tag beacon-based mobility management for communication services via I / O user equipment performing emulated user terminals as cloud computing services

Abstract

A mobility manager manages mobility of a communication service for a user through an I / O user device. A mobility manager receives beacon signal measurements and session-related information from a plurality of I / O user devices. The beacon signal measurement indicates a signal strength measurement of a beacon signal from a user tag that may be carried by a user by the I / O user device. Determining that a mobility switching rule is satisfied in response to a comparison based on beacon signal measurements of the first I / O user equipment and the second I / O user equipment, the mobility manager initiates a mobility switch of an I / O traffic flow associated with the session-related information from routing between a user terminal emulation application hosted by the user terminal emulation server and the first I / O user equipment to routing between the user terminal emulation application and the second I / O user equipment.

Description

Technical Field

[0001] The present disclosure relates to providing communication services through user terminals of a wireless communication system. Background Art

[0002] The market for user terminals is driven by the quest to provide users with increasingly advanced communications and other operating features within the constraints of a portable, handheld form factor. Development requirements for user terminals have become increasingly complex as designers seek to integrate a wider variety of user interfaces and advanced operating features within a portable, handheld form factor. Advances in operating features have required more highly integrated and faster processing circuits with greater circuit density, which has become more difficult under constraints on cost and power consumption.

[0003] This all-encompassing, feature-rich approach to user terminal development does not meet all of the diverse expectations of consumers seeking solutions for the rapidly expanding diversity of communication services. Furthermore, the always-connected expectations of today's society place an onus on users to vigilantly keep their user terminals within arm's reach or risk not being able to receive or initiate communication services in a timely manner. Summary of the invention

[0004] Some embodiments disclosed herein relate to a user tag that can be carried by a user and includes a circuit configured to perform an authentication process with an authenticator via communication through an input and / or output (I / O) user device to obtain session-related information. The circuit is also configured to send a beacon signal containing session-related information to an I / O user device located proximate to the user tag.

[0005] Some other related embodiments disclosed herein relate to an I / O user device including a circuit configured to receive a beacon signal from a user tag. The beacon signal includes session related information. The circuit is further configured to measure the signal strength of the beacon signal to generate a beacon signal measurement, and to send the beacon signal measurement and session related information for use by a mobility manager to perform mobility management of a communication service for a user, the communication service being capable of being provided by a user terminal emulation server through one or more I / O user devices.

[0006] Some other related embodiments disclosed herein relate to a mobility manager for managing mobility of communication services for users through I / O user devices. The mobility manager includes a circuit configured to receive beacon signal measurements and session related information from multiple I / O user devices, the beacon signal measurements indicating signal strength measurements of beacon signals from user tags that can be carried by users by the I / O user devices. The circuit is also configured to initiate a mobility handover of an I / O service flow associated with the session related information from being routed between a user terminal emulation application hosted by a user terminal emulation server and the first I / O user device to being routed between the user terminal emulation application and the second I / O user device in response to determining that a mobility handover rule is satisfied based on a comparison of beacon signal measurements of a first I / O user device and a second I / O user device.

[0007] Some other related embodiments disclosed herein relate to an authenticator including a circuit configured to establish a key through an authentication process with a user tag via a first I / O user device. The authenticator authenticates a beacon signal from the first I / O user device based on the key. The beacon signal is accompanied by a beacon signal measurement indicating a signal strength measurement of the beacon signal from the user tag that can be carried by the user by the first I / O user device. The beacon signal is protected using the key. The circuit is also configured to respond to the authentication of the beacon signal by sending the beacon signal measurement to a mobility manager that manages mobility of communication services for the user through the I / O user device.

[0008] Some potential advantages of these and related embodiments include that a user can receive and initiate communication services without the need for a traditional all-inclusive, feature-rich user terminal. A centralized server-based approach uses one or more networked I / O user devices located proximate to a user tag that can be carried by a user to emulate a user terminal, and wherein the I / O user devices have user interface (UI) capabilities, either individually or in combination, to provide an I / O user interface for the user to interface with a user terminal emulation application of a server to perform communication services. Various embodiments disclosed herein can provide and improve management of mobility for communication services that are currently being provided or are available to be provided by a centralized server-based approach for emulating a user terminal using (one or more) I / O user devices. Mobility management decisions can be tracked with more real-time proximity and radio conditions indicated by beacon signal measurements reported by the I / O user devices, and can be executed while maintaining secure control plane termination in the user tag and secure data plane termination in the I / O user device.

[0009] Upon review of the following figures and detailed description, other user tags, I / O user devices, mobility managers, and authenticators according to embodiments of the inventive subject matter will be or become apparent to those skilled in the art. It is intended that all such additional user tags, I / O user devices, mobility managers, and authenticators be included in this specification, be within the scope of the inventive subject matter, and be protected by the appended claims. Furthermore, it is intended that all embodiments disclosed herein may be implemented separately or combined in any manner and / or combination. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Aspects of the present disclosure are illustrated by way of example and not limitation in the accompanying drawings. In the drawings:

[0011] Figure 1 A system having a user terminal emulation server according to some embodiments of the present disclosure is illustrated, the user terminal emulation server operatively integrating a collection of I / O user devices located proximate to a user to logically form a virtualized user terminal providing communication services;

[0012] Figure 2 illustrates a block diagram illustrating a user terminal emulation server communicating with various elements of a cellular system to provide communication services according to some embodiments of the present disclosure;

[0013] Figure 3 illustrates a block diagram illustrating that a user terminal emulation server communicates with various elements of a cellular system in different ways to provide communication services according to some other embodiments of the present disclosure;

[0014] Figure 4 and Figure 5 illustrates a combined flow chart of operations and associated data flows between a user tag, an I / O user device, an Extensible Authentication Protocol (EAP) authenticator, and a user terminal emulation server, which may include an EAP server, according to some embodiments of the present disclosure;

[0015] Figure 6 illustrates a combined flow chart of operations and related data flows between a user tag, an I / O user device, a 3GPP key agreement function system, and a user terminal emulation server according to some embodiments of the present disclosure;

[0016] Figure 7 illustrates a block diagram of hardware circuit components of an I / O user device configured to operate in accordance with some embodiments;

[0017] Figure 8 illustrates a block diagram of hardware circuit components of a user terminal emulation server configured to operate according to some embodiments of the present disclosure;

[0018] Fig. 9 illustrates a block diagram of hardware circuit components of an EAP authenticator or AKMA server configured to operate according to some embodiments of the present disclosure;

[0019] Fig.10 illustrates a block diagram of hardware circuit components of a user tag configured to operate according to some embodiments of the present disclosure;

[0020] Fig.11 illustrates a block diagram of hardware circuit components of a mobility manager configured to operate according to some embodiments of the present disclosure;

[0021] Fig.12 A mobility scenario and some related mobility management operations that may be performed by a mobility manager according to some embodiments of the present invention are illustrated.

[0022] Fig.13A and 13B illustrates operations for mobility management of active sessions according to some embodiments of the present disclosure;

[0023] Fig.14 illustrates operations for mobility management during idle periods according to some embodiments of the present disclosure;

[0024] Fig.15 illustrates a flow chart of operations that may be performed by a user tag according to some embodiments of the present disclosure;

[0025] Fig.16 A flowchart illustrating operations that may be performed by an I / O user device according to some embodiments of the present disclosure;

[0026] Fig.17 illustrates a flow chart of operations that may be performed by a mobility manager according to some embodiments of the present disclosure; and

[0027] Fig.18 A flow diagram illustrating operations that may be performed by an authenticator according to some embodiments of the present disclosure is illustrated. DETAILED DESCRIPTION

[0028] The inventive concept will now be described more fully below with reference to the accompanying drawings, in which examples of embodiments of the inventive concept are shown. However, the inventive concept can be embodied in many different forms and should not be construed as being limited to the embodiments set forth 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. A component from one embodiment may be assumed by default to be present in or used in another embodiment.

[0029] Various embodiments disclosed herein relate to managing improvements in mobility for communication services provided by a centralized server-based approach for emulating a user terminal using one or more networked input and / or output (I / O) user devices. The I / O user devices are located adjacent to a mobile user carrying a user tag. The I / O user devices, either individually or in combination, have user interface (UI) capabilities that are required in order to provide an I / O user interface for a user to interface with a user terminal emulation application of a server to provide communication services to the user.

[0030] Some potential advantages of these embodiments include that users can obtain communication services without the need for traditional all-inclusive, feature-rich user terminals, i.e., traditional smart phones, mobile phones, tablet computers, etc. The user terminal emulation server can utilize the available UI capabilities of one or more I / O user devices located in the vicinity of the user to provide functions for communication services to the user terminal. The server-based approach can provide low-cost, adaptable communication services to users. As users move in and out of the vicinity of I / O user devices, the embodiments disclosed herein can achieve more operationally efficient setup and switching of communication services.

[0031] Whenever and wherever the I / O user device is in the vicinity of the user, the dynamic allocation of the I / O user device capabilities enables efficient and flexible use of existing hardware, such as televisions, conference phones, laptops, surveillance cameras, connected home appliances, connected cars, etc., which can provide the necessary UI functions to the user during the communication service. As a result, the user reduces or does not need to carry an expensive and all-inclusive user terminal (e.g., a smart phone) that includes all necessary UI capabilities, display devices, keyboards, speakers, etc. As an alternative, the user can carry a hardware device that operates to identify the user (referred to as a "UserTag" or "user tag") to one or more of the I / O user devices through a wireless or wired (e.g., smart card reader) communication interface (such as a near field communication (NFC) interface). The various embodiments disclosed herein may revolutionize the traditional mobile communication industry centered on handsets because the features and capabilities that form the user terminal are not constrained to the domain of mobile phone manufacturers. The user terminal emulation server can operate to provide a user terminal (which may also be referred to as a SoftUE) or a user terminal emulation application run by the user terminal emulation server.

[0032] Mobility management decisions for switching flows between I / O user devices may be made to track more real-time proximity and radio conditions as indicated by beacon signal measurements reported by the I / O user devices, and performed while maintaining secure control plane termination in the user tags and secure data plane termination in the I / O user devices.

[0033] Figure 1 The system with a user terminal emulation server 100 according to some embodiments of the present disclosure is illustrated, and the user terminal emulation server 100 can use one or more I / O user devices 130 located in proximity to the user to logically emulate a user terminal providing communication services. According to some embodiments of the present disclosure, the user terminal emulation server 100 can operatively integrate the UI capabilities of a collection of I / O user devices 130 to logically emulate a user terminal providing communication services.

[0034] refer to Figure 1 The user terminal emulation server 100 may be a cloud resource that is networked and remote from the I / O user device 130, or may be located more closely on a shared network with the I / O user device 130. The user terminal emulation server 100 is configured to communicate with (one or more) I / O user devices 130 located proximate to a user, and the user may use the UI capabilities of the (one or more) proximate I / O user devices 130 during the communication service.

[0035] A user may carry a hardware tag, also referred to as a "UserTag" or "user tag", which is capable of sending a unique user identifier through a communication interface, such as a near field communication interface (e.g., Bluetooth, BLE, NFC, RFID, etc., or a combination thereof) to be received by one or more of the I / O user devices 130 located in proximity to the user. One type of UserTag may be a low-complexity standalone electronic device with limited operational capabilities for sending an identifier through a near field communication interface and performing authentication operations such as those described herein. Another type of UserTag may have more operational capabilities (e.g., processing and memory hardware resources), such as a smart phone or smartwatch with a cellular connection, which sends a cellular identity (e.g., from a SIM card) or an application identity through a cellular interface or a near field communication interface and is configured to perform authentication operations such as those described herein. A UserTag may be a device that does not require human interaction in order to interact with an I / O user device and may lack a user interface. A UserTag may be configured to interact with one or more types of Internet of Things (IoT) devices, such as cameras, sensors, or other electronic devices with an Internet or other wireless connection.

[0036] The user identifier may alternatively or additionally be operationally determined by a biometric operation performed, for example, by one or more of the I / O user devices 130. The biometric operation may include, but is not limited to, one or more of voice recognition, image / face recognition, eye recognition, fingerprint recognition, or a combination thereof. The user identity may be determined based on credentials provided by the user, for example, when logging into an application or account. The user identity may be provided by a cell phone using information from a subscription SIM, and the proximity of the cell phone to one or more of the I / O user devices 130 may be determined using the NFC capability of the phone.

[0037] During a user registration process or as part of another set-up process, the user identifier, the UserTag identifier, and the user terminal emulation application 110 may be logically associated with each other in the database 120. For example, during the user registration process, the user may obtain an account login identifier (serving as a user identifier) ​​that is registered in the database 120 as being associated with a UserTag identifier for a physical UserTag that has been provided to the user (e.g., purchased by the user) and associated with a user terminal application 110 that emulates a user terminal with defined capabilities (e.g., a phone that provides cellular and over-the-type IP voice communication services).

[0038] The user terminal emulation server 100 may maintain the network addresses of the I / O user devices 130 and the UI capabilities of the I / O user devices 130 in the database 120. Although the database 120 is illustrated as residing in the example server 100, in some other embodiments, the information described below as residing in the database 120 may alternatively or additionally be stored in the IODH 212 and / or the user terminal emulation application 110. The capabilities of the I / O user devices 130 may be logically arranged in the database 120 based on the type of UI capabilities provided (e.g., display device, microphone, speaker, keyboard), and may also be arranged based on the quality of service provided by the UI capabilities.

[0039] The user terminal emulation server 100 may register the network address of one of the user terminal emulation applications 110 and the identity of the user with the network entity 150 that provides the communication service. The network entity 150 provides the communication service function 140, which may correspond to, for example, an over-the-top voice over Internet protocol (VoIP) service, a Netflix service, a Facebook service, a Microsoft Teams conference service, an Internet browser service, a cellular communication service, etc. The user terminal emulation application 110 is executed by the user terminal emulation server 100. The user terminal emulation application 110 may run one or more applications that are typically run by a smart phone, such as a Netflix application, a Facebook application, a Microsoft Teams application, an Internet browser application, etc.

[0040] like Figure 1 As illustrated, the server 100 may host a different instantiation of the user terminal emulation application 110 for each user to be provided with communication services (i.e., the illustrated user terminal emulation applications #1-#N corresponding to users 1-N). The user terminal emulation application 110 may perform registration of the user with the network entity 150 and establish communication services with the user in response to a communication request.

[0041] When the communication service function 140 of the network entity 150 is a VoIP service, the operation of registering the network address of the user terminal emulation application and the identity of the user with the network entity may include registering the network address of the user terminal emulation application 110 and the identity of the user with a network server of the VoIP communication service provider.

[0042] When the communication service function 140 of the network entity 150 is a cellular communication service, the operation of registering the network address of the user terminal emulation application and the identity of the user with the network entity may include registering the network address of the user terminal emulation application 110 and the identity of the user with a home subscriber server (HSS) or other network node of the core network operated by the cellular communication service provider.

[0043] The user terminal emulation server 100 may use the Session Initiation Protocol (SIP) / Session Description Protocol (SDP) to receive registration messages from the I / O user devices, wherein each of the registration messages identifies the network address and UI capabilities of one of the I / O user devices. The SIP / SDP may be used to receive a communication request from the network entity 150, and the SIP / SDP may be used to perform operations for providing a communication session between the user terminal emulation application 110 and each of the I / O user devices in the set, and between the user terminal emulation application 110 and the user terminal that issued the request.

[0044] The registration message from the I / O user device may include, for example, an IP address and port number, a MAC address, a fully qualified domain name (FQDN), and / or another network address, and may also include information identifying the UI capabilities of the I / O user device. The I / O user device may respond to the power-on by transmitting a registration message to the user terminal emulation server 100.

[0045] The user terminal emulation server 100 receives a communication request from a network entity 150 for establishing a communication service between a user and a requesting user terminal (e.g., a cellular phone, a computer with a Microsoft Teams application, etc.). In response to the communication request, the user terminal emulation server 100 identifies one or more of the I / O user devices 130 that can be registered in the database, which are located adjacent to the user's location and are determined based on the UI capabilities identified by the database 120 for the collection of I / O user devices and based on the content of the communication request to meet the capability rules that can be used alone or in combination to provide an I / O user interface for the user to interface with the user terminal emulation application 110 to provide communication services. Although various operations are described above and elsewhere as being performed by the user terminal emulation server 100, it will be understood that these and other operations are performed by the user terminal emulation server 100 executing one or more of the user terminal emulation applications 110 instantiated for the user.

[0046] The user terminal emulation server 100 provides one or more communication sessions between the user terminal emulation application 110 and one or more I / O user devices 130 and between the user terminal emulation application 110 and the requesting user terminal via the network entity 150. The communication request received by the user terminal emulation application 110 may contain an indication of the minimum UI capabilities that must be provided to the user during the communication service, such as: speaker only; combination of speaker and microphone; display only; combination of display device, speaker and microphone; etc. The UI capability rules that can be used by the server 100 to determine whether the communication service can be provided and by which set of I / O user devices can be provided can thus be defined based on the minimum UI capabilities indicated by the communication request.

[0047] Then, the user terminal emulation server 100 routes the communication traffic between at least one of the I / O user devices in the set and the requesting user terminal via the network entity 150. In some embodiments, for example, for each data type received as communication traffic from the requesting user terminal, the user terminal emulation server 100 selects one of the I / O user devices from the set of I / O user devices based on a matching characteristic of the data type with the UI capability identified by the database 120 for one of the I / O user devices, and then routes data of the data type to the network address of the selected I / O user device among the I / O user devices.

[0048] As will be explained in further detail below, the server 100 may also combine data streams received from the I / O user devices in the set and route the combined data stream, for example via the network entity 150, to a requesting user terminal.

[0049] The user terminal emulation server 100 (e.g., the application 110 described below or the I / O user device processor) can be responsible for tracking which I / O user devices are located adjacent to the current location of the user. The server 100 can receive an existence report from each individual I / O user device in the I / O user device, and the existence report contains their network address and the identifier of the user tag, and the user tag is determined by the I / O user device as being located adjacent to the I / O user device. For example, the I / O user device can read the user tag through the NFC communication interface and / or can perform other operations to detect the presence of the user and identify the user tag carried by the user. In response to the existence report, the server 100 updates the database 120 to indicate which user tag identifiers are located adjacent to which of the I / O user devices.

[0050] Further references Figure 1 In the example system of FIG. 1 , a set of I / O user devices 130 has been determined by the instantiated user terminal emulation application #1 to be located proximate to the location of a first user carrying UserTag #1, and also has UI capabilities that can be combined to satisfy the UI capability rule, and the UI capability rule is used to provide a combined I / O user interface for the first user to use during the requested communication service. Application #1 responsively uses the set of I / O user devices 130 to provide a combined I / O user interface for the first user to use during the communication service between the first user and another user terminal via the network entity 150.

[0051] Similarly, another set of I / O user devices 130 has been determined by the instantiated user terminal emulation application #2 to be located proximate to the location of the second user carrying UserTag #2, and also has UI capabilities that can be combined to satisfy the UI capability rule, and the UI capability rule is used to provide a combined I / O user interface for the second user to use during the requested communication service. Application #2 responsively uses the set of I / O user devices 130 to provide a combined I / O user interface for the second user to use during the communication service between the second user and another user terminal via the network entity 150.

[0052] Figure 1 It is also illustrated that another set of I / O user devices 130 are located without being adjacent to UserTag#1 or UserTag#2.

[0053] As explained above, a communication request to establish a communication service with an identified user can be initiated by the network entity 150 using the network address of the user terminal emulation application previously registered with the network entity 150 and the identity of the user. However, the communication request can be generated additionally or alternatively by one of the I / O user devices 130 in response to a command received from a user located adjacent to the network entity 150. For example, the user tag can be operated automatically or by the user's action to initiate communication with one of the I / O user devices 130. Alternatively, the user can operate a user interface provided by one of the I / O user devices 130 to initiate a combined audio and video call with another user. The user terminal emulation server 100 (e.g., an I / O device processor (IODH) or a user terminal emulation application 110 for the user) receives the communication request and the identity of the user tag. The application 110 performs the identification, provision, routing, selection and combination operations described above to set up and operate communication services between the user and other users via the network entity 150.

[0054] Further example systems and related operations will now be described to further illustrate how I / O user devices having different UI capabilities may be operatively used or combined to provide a combined UI that may be used by a user to meet the communication requirements of a communication service.

[0055] Further illustrative operations are described with respect to the following example embodiment, in which the speaker device is one of the I / O user devices 130 in the set that is capable of playing a received audio stream, and the microphone device is one of the I / O user devices 130 in the set that is capable of sensing audio to provide a microphone stream. The operations performed by the user terminal emulation application include updating the database 120 based on the content of the registration messages from the speaker device and the microphone device to identify the network addresses of the speaker device and the microphone device, and identifying the UI capabilities of the speaker device as having speaker capabilities and identifying the microphone device as having microphone capabilities. The speaker UI capabilities may identify the number of speakers provided, the sound loudness capabilities, and / or other operating characteristics. The microphone UI capabilities may identify the number of microphones provided, the sensitivity of the microphones, and / or other operating characteristics. The speaker device and the microphone device are each identified as belonging to a set of I / O user devices that are determined to be located proximate to the location of the user (e.g., UserTag#1), and are further determined to satisfy UI capability rules based on the UI capabilities identified by the database 120 to be used individually or combined to provide a combined I / O UI for the user to interface with the user terminal emulation application 110 to provide communication services. Based on determining that the speaker device and the microphone device satisfy the UI capability rules, further operations are performed to route the microphone stream received from the microphone device to the requesting user terminal (e.g., via the network entity 150). When an audio stream is received as a communication service from the requesting user terminal, the operation selects the speaker device based on matching the audio characteristics of the audio stream with the speaker capabilities identified by the database 120 for the speaker device, and then routes the audio stream to the network address of the speaker device.

[0056] Example embodiments may include, when the display device is an I / O user device in the set that can display the received video stream, the operation is based on the content of the registration message to update the database 120 to identify the network address of the display device, and the UI capability of the display device is identified as having display capability. The display UI capability can identify the screen display size, aspect ratio, pixel resolution, supported video frame rate, whether the display device supports sharing user support via split screen configuration and / or other operating characteristics. The display device is also identified as being in a set of I / O user devices, and the I / O user devices of the set are determined to meet the UI capability rule of being used alone or combined to provide a combined I / O UI for the user to interface with the user terminal emulation application 110 to provide communication services. In an optional further embodiment, the set of I / O user devices is also selected based on each of the I / O user devices that meet the rule of being located adjacent to the location of the user. Based on determining that the speaker device, display device, and microphone device satisfy the UI capability rules, further operations respond to the video stream received as a communication service from the requesting user terminal by selecting a display device based on matching the video characteristics of the video stream with the display capabilities identified by database 120 for the display device, and then routing the video stream to the network address of the display device.

[0057] In an example embodiment, operations for routing an audio stream and a video stream to the network addresses of a speaker device and a display device, respectively, may include: when audio data and video data are received in the same stream from a requesting user terminal through a first communication session: separating the audio data from the video data; routing the audio data to the network address of the speaker device through a second communication session; and routing the video data to the network address of the display device through the second communication session or a third communication session.

[0058] Example embodiments may include, when the camera device is one of the I / O user devices in the set that can provide a camera stream, operating to update the database 120 based on the content of the registration message to identify the network address of the camera device, and identifying the UI capability of the camera device as having camera capabilities. The camera UI capability may identify the number of camera pixels, image quality, light sensitivity, and / or other operating characteristics. The camera device is also identified as a member of a set of I / O user devices, the I / O user devices of the set are determined to be located adjacent to the location of the user, and are also determined based on the UI capabilities identified by the database 120 to meet the UI capability rule of being used alone or in combination with other I / O user devices in the set to provide a combined I / O UI for the user to interface with the user terminal emulation application 110 to provide communication services. Based on determining that the camera device meets the UI capability rule, further operations are performed to route the camera stream received from the camera device to the requesting user terminal, for example, via the network entity 150.

[0059] The operation for routing a microphone stream received from a microphone device and a camera stream received from a camera device to a requesting user terminal may include: receiving the microphone stream from the microphone device through a first communication session; receiving the camera stream from the camera device through the first communication session or the second communication session; combining the microphone stream and the camera stream in a combined stream; and routing the combined stream to the requesting user terminal through a third communication session, for example via network entity 150.

[0060] Example embodiments may include that when the keyboard device is one of the I / O user devices in the set that can output key selection data in response to a user's key selection in the keys of the keyboard device, the operation can update the database 120 based on the content of the registration message to identify the network address of the keyboard device, and identify the UI capabilities of the keyboard device as having keyboard capabilities. The keyboard device capabilities can identify the number of keys, the indication of whether the keyboard is a physical keyboard or a touch-sensitive input device, and / or other keyboard capabilities. The keyboard device is also identified as a member of a set of I / O user devices, the I / O user devices of the set are determined to be located adjacent to the user's location, and are also determined based on the UI capabilities identified by the database 120 to meet the UI capability rules of being used alone or in combination with other I / O user devices in the set to provide a combined I / O UI for the user to interface with the user terminal emulation application 110 to provide communication services. Based on determining that the keyboard device meets the UI capability rules, further operations are performed to identify the command formed by the key selection data received from the keyboard, and the operation that has been predefined as triggered based on the reception of the identified command is performed.

[0061] The operation for routing key selection data received from a keyboard device and a microphone stream received from a microphone device may include: receiving key selection data from the keyboard device through a first communication session, receiving a 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 in a combined stream; and routing the combined stream to a requesting user terminal through a third communication session, for example via network entity 150.

[0062] Figure 2 2 is a block diagram illustrating a user terminal emulation server 100 as an element of an operator service node 202 within a cellular system 200. Figure 2 , network entity 140( Figure 1 ) may be provided by the operator service node 202, or may be accessed through an external infrastructure 240 (e.g., the Internet). The server 100 may be implemented, for example, in the radio access network 220 to provide edge computing with faster responsiveness, or may be implemented within another node of the cellular system 200. The user terminal emulation server 100 may include an I / O user equipment processor (IODH) 212, a control function (CF) 214, an instantiated user terminal emulation application 110, and a service gateway (GW) 216. The user terminal emulation application 110 may execute one or more user applications provided by a smart phone, such as a Netflix application, a Facebook application, a Microsoft Teams application, an Internet browser application, and the like.

[0063] The user terminal emulation server 100 or the IODH 212 which may be part of the server 100 may perform operations to manage I / O user devices, such as to handle the maintenance of the database 120, perform registration of the I / O user devices so that they can be used for the user terminal emulation application 110, and manage mobility by operations for setting up communication services and performing switching of communication services via the I / O user devices. For example, the user terminal emulation server 100 may operate to identify the IP address of the user terminal emulation application (e.g., which encapsulates the Microsoft Teams application) for the subscriber using a service provider (e.g., a Microsoft Teams server). In some other embodiments, the IODH 212 may be located in another network node of the system outside the user terminal emulation server 100. The CF 214 may be responsible for assigning an IP address to each user terminal emulation application 110. The IP address to be assigned by the CF 214 may be received from a core network 210 function (e.g., a PDN-GW). The service GW 216 may interconnect the user terminal emulation server 100 to a PSTN network, a packet data network gateway of a 3GPP (third generation partnership project) system, etc. The cellular system 200 may include a core network 210 having a home subscriber server (HSS), a policy and charging role function (PCRF), a gateway (GW), and a mobility management entity (MME) that provides control signaling related to mobile terminal mobility and security for radio access. The HSS contains subscriber related information and provides the system with support functions for user authentication and user access. The PCRF implements QoS control by data flow and radio bearer by setting QoS rules for each data flow based on the policy set by the operator and subscriber information. The GW may include a serving GW (S-GW) and a packet data network GW (PDN-GW), wherein the S-GW interconnects the core network 210 with the radio access network 220 and routes incoming and outgoing packets for the I / O user equipment 232 and / or 130 and the user terminal 230. The PDN-GW interconnects the core network 210 with an external infrastructure 240 (such as the Internet), allocates IP addresses, and performs policy control and charging.

[0064] Some I / O user equipment 232 with cellular communication capabilities may communicate with the operator service node 202 via the core network 210 via, for example, an eNB or other radio access node of the radio access network 220. Figure 2 In the system, the user terminal emulation server 100 can handle setting up communication services between a set of selected I / O user devices of neighboring users and a remote user terminal 230 (eg, a smart phone) via the cellular system 200.

[0065] Figure 31 is a block diagram illustrating that a user terminal emulation server 100 communicates with various elements of a cellular system 200 in different ways according to some embodiments of the present disclosure. The cellular system 200 may be a network entity 140 ( Figure 1 ) operates to provide communication services. Figure 3 system and Figure 2 The difference of the system is that the user terminal emulation server 100 is an Internet service within the external infrastructure 240 outside the cellular system 200. Figure 3 In a system of FIG. 2 , CF 214 may determine IP addresses to be assigned to different user terminal emulation applications 110 based on signaling from an Internet service within external infrastructure 240 .

[0066] The above-described and other example operations will now be described in further detail in the context of two different example "use cases": 1) an incoming call scenario; and 2) an outgoing call scenario.

[0067] Use Case 1: Incoming call scenario operation is now discussed below.

[0068] This use case involves a user with a user tag or other means of being identified being located proximate to an I / O user device 130 with different UI capabilities when a user terminal emulation server receives an incoming call. Although the operations are explained below in the context of identifying a user through a physical user tag carried by the user, the operations are not limited thereto and may be used with any other means of identifying a user, such as by sensing biometric information identifying the user and involving operational communications with a user tag carried by the user.

[0069] The user terminal emulation application 110 may be instantiated or otherwise activated responsively by an incoming call (service, session) for a user tag. The user terminal emulation application 110 may identify a subscription associated with the user tag (e.g., registered in a user account) and a preferred communication method (e.g., audio rather than video, audio and video, etc.) that has been specified by the user, and determine the UI capabilities of the I / O user devices that will be required to satisfy the UI capabilities that may be specified for the incoming communication session. The user terminal emulation application 110 may request the IODH to identify which I / O user devices 130 are located adjacent to the user tag, and may further request the IODH to determine or may determine itself whether the identified I / O user devices 130 may be used individually or in combination to satisfy the UI capabilities specified for the incoming communication session. The user terminal emulation application 110 and / or the IODH may receive a returned ACK or NACK regarding whether a sufficient set of I / O user devices 130 may be used to provide communication services. If it is ACK, the IODH also sets the status of the I / O user device 130 in the set to be in use to prevent another user terminal emulation application 110 from trying to use the same I / O user device 130 as the I / O user device 130 currently in use.

[0070] In the case of a NACK, the user terminal emulation application 110 and / or the IODH may take different actions to set up a communication service with the user that reduces UI capabilities, depending on the user settings, e.g., in response to no display device currently being available, only voice-based communication is allowed, instead of a combination of voice and video. An example where no display device is available may occur when, during an ongoing communication service, the only display device located proximate to the user is currently being used by another user to receive information from another user terminal emulation application, or when no display device is located proximate to the user.

[0071] Further operations performed by the user tag, the I / O user device, and the user terminal emulation server are described according to this example use case. The user tag enters the room and uses a discovery beacon signal to signal its presence to any I / O user device in the room that is located adjacent and capable. Alternatively, one or more of the I / O user devices determine the presence of the user tag by polling, such as by periodically sending a discovery beacon signal that triggers responsive signaling of the user tag. The I / O user device that receives the signaling indicating the presence of the user tag reports to the IODH 212 along with the network address of the I / O user device (e.g., IP address, port number, MAC address, FQDN, etc.). The IODH 212 can be executed by a user terminal emulation server as part of a user terminal emulation application, by an I / O user device, and / or by another computing node of the system. The user terminal emulation application corresponding to a specific user (i.e., a user tag) is updated regarding the presence of the detected user. The IODH 212 can be operated to receive notifications from I / O user devices that are located adjacent to the user tag. Further UI capability discovery (synchronization) communication is performed between the user terminal emulation server and the I / O user device. The I / O user device is associated with the user in the database 120, and the associated indication subscription, and the combinable UI capability provided by the set of I / O user devices located adjacent to the user tag. One or more of the I / O user devices can be selected to receive ACK / NACK by default call. The user is now known to be connected in the system by the set of the identified I / O user devices with the identified UI capability (e.g., speaker yes / no, display yes / no, microphone yes / no, keyboard yes / no, etc.) via the user tag, thereby creating a logical virtualized user terminal, through which the user can be provided with services in the communication service. The user can initiate the communication service by the voice command sensed by the touch screen, microphone, the definition gesture observable by the execution camera and / or other input provided to one of the I / O user devices located adjacent to the location.

[0072] An incoming session (e.g., a video call) directed to a user (user tag) from a requesting user terminal arrives at a user terminal emulation server for the user carrying the user tag. The UI capabilities of the available I / O user devices, either individually or in combination, are compared with the UI requirements of the incoming session. When the UI capabilities of the I / O user device do not meet the UI requirements of the incoming session, the user terminal emulation server may renegotiate the required UI capabilities (e.g., QoS) of the incoming session. On the contrary, when the UI requirements of the incoming session are met, the user terminal emulation server prompts the user carrying the user tag to provide a session request response (ACK / NACK) via one or more of the available I / O user devices (e.g., a pre-selected answering device). The user responds through the pre-selected answering device to accept (ACK) or reject (NACK) the incoming session to provide signaling to the user terminal emulation server. When ACK is received, the operation routes the audio stream from the requesting user terminal via one or more sessions to one of the I / O user devices in the set with speaker capabilities, and routes the video stream from the requesting user terminal via one or more sessions to another I / O user device with display capabilities in the I / O user devices in the set. The data stream received from one of the I / O user devices in the set through one or more sessions is routed to the requesting user terminal. When two or more data streams are received from the I / O user devices through one or more sessions, they can be combined into a combined data stream, which is routed to the requesting user terminal.

[0073] The user terminal emulation server or IODH may perform operations to continuously monitor the presence of I / O user devices to determine when one or more of the I / O user devices is no longer located proximate to the user such that it can no longer be included as part of the combined UI to be provided during the ongoing communication session. The user terminal emulation server or IODH may substitute the UI capabilities of another I / O user device into the set being used by the user for the ongoing communication session in response to the previous member of the set no longer having the required presence status.

[0074] Use Case 2, outgoing call operation is now discussed below.

[0075] This use case involves a user with a user tag being located adjacent to an I / O user device 130 with different UI capabilities when the user terminal emulation server receives an outgoing call (communication session). The I / O user device 130 is associated with the identified user via the user terminal emulation server 100 that handles all communication sessions for the user, and the associated I / O user device 130 is managed by the IODH 212.

[0076] The user terminal emulation application 110 may be instantiated or otherwise activated for responsiveness by an outgoing call being requested by a user carrying the user tag. The user may initiate an outgoing call by a touch screen, a voice command sensed by a microphone, performing a defined gesture observable by a camera, and / or other input provided to one of the I / O user devices in close range.

[0077] The user terminal emulation application 110 may identify the subscription associated with the user tag and the preferred communication method (e.g., audio instead of video, audio and video, etc.) that has been specified by the user, and determine the UI capabilities of the I / O user device that will be required to satisfy the UI capabilities that may be specified for the outgoing call. The user terminal emulation application 110 may request the IODH 212 to identify which I / O user devices 130 are in range of the user tag, and may also request the IODH 212 to determine or may determine itself whether the identified I / O user devices 130 may be used individually or in combination to satisfy the UI capabilities specified for the outgoing call. The user terminal emulation application 110 and / or the IODH 212 may receive a returned ACK or NACK regarding whether an I / O user device 130 or a collection of I / O user devices 130 may be used to provide communication services. If it is ACK, the IODH 212 also sets the status of one or more I / O user devices 130 in the set to be in use to prevent another user terminal emulation application 110 from trying to utilize the same (one or more) I / O user devices 130 as the I / O user devices currently in use. In the case of NACK, the user terminal emulation application 110 and / or the IODH 212 may take different actions to establish a communication service with reduced UI capabilities with the user depending on the user settings, for example, in response to no display device currently available for use (e.g., when currently being used by another user terminal emulation application 110, or when no display device is located adjacent to the user's tab), only allowing sound instead of preferred sound and video.

[0078] Example operations for outgoing calls and related data flows between a user tag, an I / O user device, and a user terminal emulation server are now described in the context of this use case. A user tag enters a room and signals its presence to any nearby and capable I / O user devices in the room using a discovery beacon signal. Alternatively, one or more of the I / O user devices determine the presence of the user tag by polling, such as by periodically sending a discovery beacon signal that triggers responsive signaling of the user tag. The I / O user device that receives the signaling indicating the presence of the user tag reports to the IODH 212 along with the network address or other identifier of the I / O user device (e.g., IP address, port number, MAC address, FQDN, etc.). The IODH 212 can be executed by a user terminal emulation server as part of a user terminal emulation application, by an I / O user device, and / or by another computing node of the system. The user terminal emulation application corresponding to a particular user (i.e., a user tag) is updated regarding the detected presence of the user.

[0079] IODH 212 can be operated to receive notifications from I / O user devices located adjacent to the user tag. Further UI capability discovery (synchronization) communication is performed between the user terminal emulation server or IODH and the I / O user device. The I / O user device is associated with the user in the database 120, and the associated indicated service subscription and the combinable UI capability provided by the set of I / O user devices located adjacent to the user tag. One or more of the I / O user devices can be selected to receive ACK / NACK by default call. The user is now known via the user tag as being contactable within the system through the set of identified I / O user devices with the identified 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 services in the communication service. The user can initiate the communication service through a touch screen, a voice command sensed by a microphone, a defined gesture observable by a camera, and / or other inputs provided to one of the I / O user devices located adjacent to the range.

[0080] The user carrying the user tag triggers an outgoing call (e.g., a video call) using the UI of one of the I / O user devices, which triggers the signaling of the outgoing call sent to the user terminal emulation server. The IODH 212 and / or the user terminal emulation application queries the user (e.g., displays a message, generates a sound, etc.) through one of the I / O user devices located adjacent to the user to request the user to select from the available types of communication methods that can currently be used for the outgoing call. One of the I / O user devices provides responsive signaling to the IODH 212 or the user terminal emulation server 100, indicating the user's selected type of communication method for the outgoing call. The user terminal emulation server transmits an outgoing session flow request to the network entity 150, wherein the request may include an identifier of the calling user, an identifier of the user terminal of the called user, and a quality of service for the communication session. The user terminal emulation server receives a communication session acceptance (ACK) or rejection (NACK) from the network entity 150. When the communication session is rejected, the user terminal emulation server may attempt to renegotiate the requested communication session, such as with a lower quality of service.

[0081] When the communication session is accepted (ACK), for each data type received as a communication service from the requested user terminal, the user terminal emulation server selects one of the I / O user devices from the set of I / O user devices based on matching the characteristics of the data type with the UI capabilities identified for one of the I / O user devices by the database 120, and then routes the data of the data type to the network address of the selected one of the I / O user devices. The I / O user device sends the data streams through one or more sessions to the user terminal emulation server, which can combine the data streams into a combined data stream, which is routed to the called user terminal via the network entity 150.

[0082] The user terminal emulation server or IODH may continuously monitor the presence of the I / O user devices to determine when one or more of the I / O user devices is no longer located proximate to the user such that it can no longer be included as part of the combined UI to be provided during the ongoing communication session. The user terminal emulation server or IODH may substitute the UI capabilities of another I / O user device into the set being used by the user for the ongoing communication session in response to the previous member of the set no longer having the required presence status.

[0083] Safety issues and related operations are now discussed below.

[0084] In some systems, it may be desirable to provide operations for virtual instances (eg, virtual terminal emulation application 110) in a cloud (eg, user terminal emulation server 100) to dynamically protect usage of physical resources using authentication and key establishment procedures.

[0085] Some embodiments involve using a trusted party (function) to enable secure access and communication between a cloud service (e.g., a user terminal emulation server 100 (also referred to as a "cloud phone")) and (one or more) I / O user devices 130. Some embodiments involve extending existing authentication functions to Figure 1-3 A secure association is established between the various elements of the described system, in particular between the user terminal emulation server 100, the I / O user device(s) 130 located proximate to the user, and the user tag carried by the user.

[0086] In some embodiments, a user who has registered and authenticated to the cloud service carries a user tag that has been associated (e.g., via a user identity) with the user terminal emulation server 100, such as in the database 120. As explained above, there may be many I / O user devices 130 associated and registered with the lookup service (e.g., IODH 212).

[0087] When the user enters the close proximity of at least one I / O user device 130, operations are performed based on the Extensible Authentication Protocol (EAP), Authentication and Key Management for Applications (AKMA), or another security function to establish a security association between the user terminal emulation server 100, the (one or more) I / O user devices 130 located in close proximity to the user, and the user tag carried by the user. The security association enables the user terminal emulation server 100 to utilize the UI capabilities of these I / O user devices 130 to obtain communication services.

[0088] In some example scenarios, the user tag is (also) a constrained device carried by the user to identify the user and is capable of short-range radio signaling (e.g., near field communication (NFC), Bluetooth, etc.) and / or long-range radio signaling (e.g., WiFi, cellular, etc.). The user tag is registered and authenticated with (one or more) I / O user devices 130. At least one I / O user device 130 has a local service that provides certain UI capabilities, which can be registered with the user terminal emulation server 100 or IODH 212 to be included in the lookup service provided by the database (e.g., database 120), and / or can reside in IDOH 212 and / or I / O user device 130.

[0089] Although some embodiments are described in the context of user terminal emulation server 100 being a cloud-based service, these and other embodiments are not limited thereto. The operations disclosed herein can be used to enable authenticated users to securely couple physical resources residing on a separate private network to a cloud-based service. A cloud-based service can be a telephone service, a video conferencing service, a streaming media service, a video-on-demand service, an audio-on-demand service, a network service, a digital assistant service, a service technician service, and / or any other service that can be operated to be communicatively connected to a physical resource in a user's proximity.

[0090] Various embodiments are now explained in the context of EAP-based authentication operations and AKMA-based authentication operations, respectively, although these operations can be used with any security function operations capable of facilitating secure access. In some embodiments, the user terminal emulation server 100 performs operations to establish a secure channel connection with the first I / O user device 130 using a session identifier and an identifier associated with the first I / O user device to determine a first I / O user device-specific key generated from a master key, the first I / O user device-specific key and the session identifier being used for secure communication of messages with the first I / O user device. These operations receive an indication of the I / O user interface capabilities of the first I / O user device 130 through a secure channel connection with the first I / O user device 130. These operations communicate with the first I / O user device 130 to provide at least a portion of a communication service for a user using the I / O user interface capabilities.

[0091] These and other related operations are described first in the context of EAP-based authentication, and then in the context of AKMA-based authentication.

[0092] EAP-based authentication and related operations are now discussed below.

[0093] EAP is an authentication framework that supports multiple authentication methods. EAP typically runs directly on the data link layer (such as Point-to-Point Protocol (PPP) or IEEE 802) without the need for IP. EAP provides its own support for deduplication and retransmission, but relies on ordering guarantees at lower layers. Fragmentation is not supported within EAP itself; however, individual EAP methods may support fragmentation.

[0094] EAP is a two-party protocol used between an EAP peer and a server. Within EAP, keying material is generated by an EAP authentication algorithm (called a "method"). Part of this keying material can be used by the EAP method itself, and part of this material can be exported. In addition to exporting keying material, an EAP method can also export related parameters, such as the authenticated peer and server identities and a unique EAP session identifier, and can import and export lower-layer parameters called "channel binding parameters" or simply "channel binding".

[0095] From RFC 5247: "EAP methods that support key derivation and mutual authentication SHOULD derive a method-specific EAP session identifier, called the Session-Id...". Exporting may require providing the exported information to an EAP authenticator.

[0096] An example flow of an EAP exchange for access authentication (802.1x for WLAN / LAN) may include a device attaching to an authentication point (AP). This means that an 802.11 association (for example) is established between the device and the AP. The AP requests the identity of the device using an EAP Identity Request message. The device replies with its identity in an EAP Response message. The AP, acting as an authenticator, forwards the identity to the authentication server in a RADIUS or DIAMETER Access Request message.

[0097] The authentication server replies with a challenge for the device and indicates the EAP method to be used. The AP forwards the request to the device in an EAP Request message. The device responds to the EAP message with an EAP Response message. The AP forwards the response to the authentication server in a RADIUS or DIAMETER message. EAP messages are exchanged between the device and the authentication server until the authentication server has authenticated the device using the selected method. The authentication server sends a RADIUS or DIAMETER Access-Accept message containing a pairwise master key (PMK) to the AP. The AP retains the PMK and forwards the success to the device in an EAP Success message. The device generates the corresponding PMK. The device is authenticated, and the AP and device can configure access security using the PMK. EAP can also run to authenticators other than the WLAN AP, and the authenticator can be co-located with / part of the authentication server.

[0098] Reference now Figure 4 The operation based on EAP between the user tag 110 and the user terminal emulation server 110 which can operate the EAP server (function) is described. Figure 4A combined flow chart of operations and associated data flows between user terminal emulation application 110 and elements of I / O device (IOD) domain 410, such as I / O user device 130, lookup service / IODH, and extensible authentication protocol (EAP) authenticator 400, according to some embodiments of the present disclosure is illustrated. For the sake of brevity, the term "I / O device" is abbreviated as "IOD" when discussing various example operations below.

[0099] refer to Figure 4 , the assumption in the EAP-based approach is that the user tag is carried with the user and contains circuits configured to operate as an EAP client. Therefore, the user tag has at least limited communication and computing capabilities. An example user tag may be a smart card with NFC or other short-range communication (such as capacitive communication coupling), or may be an electronic device with Bluetooth and / or other communication capabilities. The I / O user device 130 registers with its (local) IODH 212, which acts as a lookup service for I / O user devices (IOD A...IOD x) in the local IOD domain 410, i.e., the IODH 212 has information characterizing the I / O user device (IOD A...IOD x), which may include an identifier, authentication credentials (e.g., a public key of the I / O user device (IOD A...IOD x)), the location of the I / O user device (IOD A...IOD x) (geographic coordinates, room number, floor number, etc.), definition type information, definition UI capabilities, etc. In some embodiments, the user terminal emulation application 110 may be executed within the IOD domain 410, such as with the EAP authenticator 400 and / or the IODH 212. Executing the user terminal emulation application on the same computing node or local networking node as the EAP authenticator and / or the IODH may simplify and reduce system resources consumed by exchanging information and other communications therebetween.

[0100] Which users and / or user terminal emulation applications are allowed to interact with I / O user devices (IOD A…IODx) in the IOD domain 410 can be determined based on an access control policy, which can reside in the IODH 212 and can vary depending on the use case scenario (e.g., a semi-public domain (such as a hotel) versus a private domain (such as a corporate office complex)).

[0101] exist Figure 5In the scenario where a user carrying user tag 101 (such as a dongle) wants to utilize an I / O user device (IOD A) in the vicinity of their location. The user can trigger the I / O user device (IOD A) by pressing a button on the user tag 101, and trigger a command in response to seeing the service set identifier (SSID) or Bluetooth (BT) address of the I / O user device (IOD A) and / or the I / O user device (IOD A). For example, the user can use an NFC-based user tag (i.e., very close proximity) and / or by the user pressing a button on the I / O user device to initiate a bootstrapping process 501 to activate or initiate attention from the I / O user device (IOD A).

[0102] The user tag sends a 502 attachment request to the system to which the I / O user device is connected via the I / O user device (the target). The I / O user device forwards 503 the attachment request to the EAP authenticator 400 in the system. The EAP authenticator 400 can be a local process in the I / O user device (IOD A) or in the IODH 212 of the user terminal emulation server 100, or can reside as a separate entity in the IOD domain 410. Thus, the attachment request can be processed by the I / O user device itself, i.e., in the case where there are multiple EAP authenticators in the system, by the IODH 212 or by the EAP authenticator 400.

[0103] The EAP authenticator 400 responds 504 with an EAP identity request sent back to the user tag 101.

[0104] The user tag 101 responds 505 with an EAP response that carries the identity of the user tag 101. This identity identifies the user tag 101 (e.g., the holder of the user tag, such as the user), and points to the user terminal emulation application 110 associated with the user tag 10. The identity can be <hash(user_pub_key)>@<user_terminal emulationapplication_address> (<hash(user_public_key)>@<user_terminal emulation application_address>). The hash of the public key provides a more compact identity of the public key of the user tag 101 and can be included together with the network address of the user terminal emulation application 110. As explained above, the user terminal emulation application 110 can provide communication service functions corresponding to, for example, over-the-top Internet protocol voice (VoIP) services, Netflix services, Facebook services, Microsoft Teams meeting services, Internet browser services, cellular communication services, etc.

[0105] When the user tag 101 has been issued to the user, it may also have been associated with the corresponding user terminal emulation application 110. This means that the user tag 101, in addition to its own credentials (e.g., a public key pair), may also be configured with the reachability information (e.g., a fully qualified domain name (FQDN)) of the user terminal emulation application 110 and the credentials for authentication of the user terminal emulation application 110 (e.g., the public key of the user terminal emulation application 110). Likewise, the user terminal emulation application 110 may have been configured with the credentials of the user tag 101 (e.g., the public key of the user tag 101). This means that the user terminal emulation application 110 knows that the user tag 101 is an entity authorized to request data flows and services from the user terminal emulation application 110.

[0106] EAP authenticator 400 identifies user terminal emulation application 110 based on the realm portion of the identifier and forwards the request to user terminal emulation application 110, which acts as an EAP server here (referred to as "EAP server / user terminal emulation application 110" for brevity).

[0107] The EAP authenticator 400 first establishes 506a a secure connection between itself and the EAP server / user terminal emulation application 110. EAP messages are passed through this secure channel between the authenticator and the EAP server / user terminal emulation application 110. The secure connection can be a transport layer security (TLS) session. The EAP authenticator 400 knows that it needs to have a session with the EAP server / user terminal emulation application 110 based on the identity (the domain part of the identity) received 506b in the EAP identity response. It also knows that it needs to have a secure channel with the EAP server / user terminal emulation application 110. Therefore, if there is no existing secure session (typically TLS), the EAP authenticator 400 creates a secure session and then forwards 506b the identity response to the EAP server / user terminal emulation application 110. When using EAP messages, the communication between the EAP server / user terminal emulation application 110 function of the EAP authenticator 400 and the user terminal emulation application 110 can be carried by the DIAMETER or RADIUS protocol.

[0108] The user terminal emulation application / EAP server 110 and the user tag 101 will perform an EAP exchange 507 to authenticate the user tag 101 to the user terminal emulation application 110. The EAP server / user terminal emulation application 110 may also authenticate the user tag 101. Authentication may require multiple messages to be exchanged between the user tag 101 and the EAP server / user terminal emulation application 110 via the EAP authenticator 400.

[0109] Once the user tag 101 and possibly the EAP server / user terminal emulation application 110 are successfully authenticated, the EAP server / user terminal emulation application 110 may send 508 a final EAP SUCCESS message to the EAP authenticator 400. The EAP SUCCESS message also carries a master key, such as a pairwise master key (PMK) and a session-ID. The PMK key is a master key for the session-ID, and the PMK key may be used to derive more keys for the I / O user device (e.g., IOD X) added to the session.

[0110] In optional operation, the user tag 101 may derive a master key, such as a PMK key, at this stage, but it will not (necessarily) be used by the user tag 101. If the user wants to authorize additional I / O user devices (e.g., IOD X), the master key may be used, assuming that the user has more control over which I / O user devices are added to the session by not having to actively (perhaps even physically) add more I / O user devices to the EAP server / user terminal emulation application 110.

[0111] The authenticator generates 509 an I / O user device specific key K_iodA from the received keying material for use in streaming data between the user terminal emulation application 110 and the target I / O user device 10D A. Generating the I / O user device specific key K_iodA may include using the received keying material as is, or may include performing a computational operation on the received keying material, such as by hashing a concatenation of the keying material and an identifier of the target I / O user device 10D A and / or using another key derivation function (KDF) based on the PMK and the I / O user device specific information.

[0112] The EAP authenticator 400 provides 510 the I / O user device 10D A with the I / O user device specific key K_iodA, as well as the session-ID derived by the EAP server / user terminal emulation application 110 and the address (eg FQDN) of the user terminal emulation application 110 .

[0113] The I / O user device 10D A may use the received data to establish a 511 secure channel (e.g., TLS) between itself and the user terminal emulation application 110. It is worth noting that, in some embodiments, in order to establish a secure channel between the I / O user device 10D A and the EAP server / user terminal emulation application 110, there is a shared key (which is a first I / O user device specific key K_iodA), an identifier for the entity (IOD A) that is connecting to the EAP server / user terminal emulation application 110 and is used to derive the I / O user device specific key, and an identifier (session-ID) that the EAP server / user terminal emulation application 110 can use to look up the context from which it can derive the corresponding K_iodA.

[0114] If the EAP authenticator 400 is part of the I / O user device 10D A, the I / O user device can reuse the TLS session established in operation 506. However, a more scalable solution is enabled by using a unified operation for all I / O user devices connected to the EAP server / user terminal emulation application 110 so that there are no special cases in the implementation.

[0115] In operation 511, the I / O user device 10D A may indicate the session / keying material / authentication context involved in the connection request to the EAP server / user terminal emulation application 110 using the session-ID.

[0116] The EAP server / user terminal emulation application 110 locates the context and associates the keying material based on the received session-ID. As background, IOD A will connect to the EAP server / user terminal emulation application 110 using a secure channel so that the EAP server / user terminal emulation application 110 can stream or receive data from IOD A, so that IOD A needs to have keying material that it can use to establish a secure connection, and the user terminal emulation application 110 needs to verify that IOD A is authorized to send data. Therefore, the session ID sent in operation 508 is a session ID that IOD A can send to the EAP server / user terminal emulation application 110, so the EAP server / user terminal emulation application 110 knows that the request relates to an authentication session established for the session ID, and then locates its copy of the PMK key and any other keys negotiated during authentication.

[0117] The I / O user device uses its own identifier (e.g., IOD A) as a kind of username. IOD A thereby tells the EAP server / user terminal emulation application 110 who it is. The EAP authenticator 400 has derived the IOD A-specific key based on the PMK key (e.g., by concatenating the IOD A ID and the PMK key and then hashing the concatenated string), and the hash value may be truncated to a defined length. The EAP server / user terminal emulation application 110 needs to know the ID for IOD A so that it can derive the same IOD A-specific key provided to IOD A, for example, in step 510.

[0118] The EAP server / user terminal emulation application 110 uses the I / O user device identifier to derive an IOD A specific key (K_iodA). IOD A uses the received key K_iodA as a password / authentication credential to authenticate to the EAP server / user terminal emulation application 110. In this operation, the I / O user device 10OD A and the EAP server / user terminal emulation application 110 share the same IOD A specific key, which is used as a shared key for the EAP server / user terminal emulation application 110 and the I / O user device 10OD A to authenticate each other and establish a secure channel therebetween. The EAP server / user terminal emulation application 110 verifies via PSK-based authentication that the I / O user device does possess a valid session key (K_iodA), and is therefore authorized to connect to the EAP server / user terminal emulation application 110 and exchange data therewith. A secure channel is established between the I / O user device 10OD A and the EAP server / user terminal emulation application 110.

[0119] After successful authentication, the I / O user device 10D A can indicate 512 its UI capabilities (e.g., display, speaker, microphone, etc.) to the user terminal emulation application 110, and the user terminal emulation application 110 can enable data streaming to and / or from the I / O user device 10D A based on the UI capabilities.

[0120] The user may have defined policies to the EAP server / user terminal emulation application 110 regarding what operations can be automatically enabled (e.g., streaming video to a display device for communication services) and what operations require explicit user consent before execution (e.g., enabling use of a microphone for communication services).

[0121] In a parallel optional operation, the EAP server / user terminal emulation application 110 may be operable to interact 513 with the IODH 212 regarding other I / O user devices in the vicinity of the user that have UI capabilities that may be used to provide communication services to the user. These operations may provide the EAP server / user terminal emulation application 110 with information about what UI and / or I / O capabilities are available to the user for communication services. Whether the EAP server / user terminal emulation application 110 may be operable to interact 513 with the IODH 212 regarding other I / O user devices may depend on which services and / or applications are running in the EAP server / user terminal emulation application 110.

[0122] This communication can be performed via an entity of the I / O user device domain 410 acting as an EAP authenticator 400 to the EAP server / user terminal emulation application 110, and thus the already established secure channel can be reused. Alternatively, the EAP authenticator 400 can generate a session key specific to the IODH 212 (similar to the operation performed for IOD A) and provide all relevant information (e.g., K_iodh, session-ID, EAP server / user terminal emulation application 110 FQDN) to the IODH 212 for secure communication with the user terminal emulation application 110.

[0123] IODH 212 itself may be EAP authenticator 400, in which case much of the "communication" between the authenticator and IODH 212 is simplified, such as where IODH 212 uses the PMK directly to securely communicate with user terminal emulation application 110, or reuses an already established secure session.

[0124] The communication may include the IODH 212 telling the user terminal emulation application 110 about which I / O user devices are available to the user, and may include the EAP server / user terminal emulation application 110 requesting the IODH 212 for specific HW resources.

[0125] When the IODH 212 concludes or the EAP server / user terminal emulation application 110 requests that some other I / O user device (IOD X) should join the session established between the user and the IOD domain 410, the IODH 212 may request 514a the EAP authenticator 400 to generate credentials (e.g., K_iodx, Session-ID, EAP server / user terminal emulation application 110 FQDN) for the other I / O user device (IOD X) and provide these credentials to the other I / O user device (IOD X).

[0126] The IODH 212 may send 514a the request based on a user indicating the EAP server / user terminal emulation application 110 (e.g., through a connection with some already connected I / O user devices) or based on local policies and / or configurations. The decision to need another I / O user device may depend on: which application and / or service the user has activated; ongoing applications and / or services; available devices and their respective UI capabilities; and / or user-defined configurations to always try to find an I / O user device with (one or more) specific UI capabilities.

[0127] If the other I / O user device 10D X receives 514c a trigger from the EAP authenticator 400 (e.g., where the trigger is a credential required to connect to the user terminal emulation application 110, etc.), the other I / O user device 10D X performs operations similar to those performed on the I / O user device 10D A described above in operations 511 to 512.

[0128] Reference now Figure 4 and Figure 5 Describes more general operations.

[0129] The embodiments are not limited to Figure 5 4 and discussed above. For example, the user tag 101 may more generally include circuitry configured to send 502 an attachment request to a first I / O user device 130 (which may correspond to IOD A) and receive 504 an identity request from the authenticator 400 from the first I / O user device 130. The user tag 101 then sends 505 a response to the I / O user device, the response including an identifier of the user tag and an address of a user terminal emulation application 110 hosted by the user terminal emulation server 100. The user tag 101 then communicates 507 with the user terminal emulation application (110) to perform an exchange for mutual authentication and establish a master key for generating one or more I / O user device specific keys.

[0130] The circuitry of the user tag 101 may be powered by the NFC reader circuitry of the first I / O user device 130 to send 502 an attachment request, receive 504 an identity request, send 505 a response, and communicate 507 with the user terminal emulation application 110 to perform the exchange. The circuitry may also be configured to generate 505 an identifier of the user tag based on hashing the public key of the user tag.

[0131] The user terminal emulation server 100 is generally configured to provide communication services through an I / O user device 130, and includes at least one processor 1200 ( Figure 8 ) and at least one memory 1220 (which stores program codes executable by at least one processor to perform operations Figure 8The operation includes establishing 405 ( ) a session with the first I / O user device (130) using the session identifier and an identifier associated with the first I / O user device to determine a first I / O user device specific key generated from a master key. Figure 4 ) and 511( Figure 5 ) secure channel connection, wherein a first I / O user device specific key and a session identifier are used for secure communication of messages with the first I / O user device. The first I / O user device specific key can be determined based on the I / O user device identifier, such as an I / O user device key (e.g., KDF(PMK, I / O user device ID), where KDF is a key derivation function. The operation receives 405 and 512 an indication of the I / O user interface capabilities of the first I / O user device 130 through the secure channel connection with the first I / O user device 130. The operation communicates 405 and 512 with the first I / O user device 130 to use the I / O user interface capabilities to provide at least a portion of the communication service for the user.

[0132] The operation of the EAP server / user terminal emulation application 110 may also include receiving 506b an EAP response through a communication channel with the EAP authenticator 400, wherein the EAP response includes an identifier of the user tag 101. The operation communicates 507 with the user tag 101 to perform an EAP exchange for authentication and establish a master key, and sends 508 an EAP success message to the EAP authenticator 400, wherein the EAP success message includes the master key and a session identifier associated with the master key. Note that IOD A has communicated with the user terminal emulation application to authenticate using the IOD A specific key. After sending 508 the EAP success message to the EAP authenticator 400, the operation performs receiving 405 an indication of the I / O user interface capabilities of the first I / O user device 130, and communicating 405 with the first I / O user device 130 to provide at least a portion of the communication service for the user using the I / O user interface capabilities.

[0133] The operation of the user terminal emulation server 100 may also include the following steps: Figure 1 ) stores an identifier of a user tag that is allowed to access the communication service, a network address of the first I / O user device based on communication with the first I / O user device, a first I / O user device specific key, and an indication of the I / O user interface capabilities of the first I / O user device 130.

[0134] Note that initially, the user terminal emulation server 100 (i.e., via the EAP server / user terminal emulation application 110) stores the session identifier and PMK. When the I / O user device connects to the user terminal emulation server 100, as part of the connection establishment process, the I / O user device provides its identifier to the user terminal emulation server 100. The user terminal emulation server 100 can now generate an I / O user device specific key. Using the I / O user device specific key, the user terminal emulation server 100 can authenticate the I / O user device, and thereafter a secure channel can be established between the two. The I / O user device has obtained the corresponding key from the EAP authenticator 400 in the IOD domain 410. The I / O user device can also optionally use the key to authenticate the user terminal emulation application 110 (i.e., verify that the user terminal emulation application 110 belongs to the session because it has the key associated with it). The I / O user device specific key can be generated by the user terminal emulation application 110 only after the user terminal emulation application 110 has learned the ID of the I / O user device specific key. In some embodiments, when the I / O user device attempts to connect to the EAP server / user terminal emulation application 110, the EAP server / user terminal emulation application 110 learns the I / O user device identifier.

[0135] In some embodiments, the sequence of events includes the I / O user device connecting to the EAP server / user terminal emulation application 110 (using its own ID, session ID, and I / O user device specific key). The EAP server / user terminal emulation application 110 identifies the session context based on the session ID. The EAP server / user terminal emulation application 110 derives the I / O user device specific key (and may store it in the database 120). The EAP server / user terminal emulation application 110 and the I / O user device authenticate based on the I / O user device specific key. Then, a secure channel may be established based on the I / O user device specific key.

[0136] The operation of establishing 405 a secure channel connection with the first I / O user device 130 using the session identifier and an identifier associated with the first I / O user device to determine a first I / O user device specific key generated from a master key may include receiving a secure channel connection request including an identifier of the first I / O user device 130 and a session identifier, and initiating determination of the first I / O user device specific key based on the master key. The operation stores the first I / O user device specific key in association with the session identifier in the database 120. The operation obtains the first I / O user device specific key from the database 120 using the session identifier, authenticates the first I / O user device based on the first I / O user device specific key, and establishes a secure channel connection with the first I / O user device 130 in response to the authentication of the first I / O user device.

[0137] The corresponding operation of the EAP authenticator 400 is now described. The EAP authenticator 400 may include at least one processor 930 ( Fig. 9 ), at least one memory 940 (which stores program codes executable by at least one processor to perform operations) Fig. 9 ). The operation includes receiving 505 an EAP response from the first I / O user device 130, the EAP response including an identifier of a user tag, the identifier of the user tag including an address of a user terminal emulation application 110 hosted by the user terminal emulation server 100. The operation establishes 506a a communication channel with the user terminal emulation application 110 based on the address of the user terminal emulation application 110 in the user tag, and sends 506b at least one EAP message based on the EAP response through the communication channel with the user terminal emulation application 110. The EAP authenticator 400 also receives an EAP message from the user terminal emulation application 110. Typically, the EAP authenticator 400 transmits EAP messages between the user tag 101 and the user terminal emulation application 110. The operation receives 508 an EAP success message from the user terminal emulation application 110, wherein the EAP success message includes a master key and a session identifier, and generates 509 a first I / O user device specific key based on the master key. The operation then sends 510 the first I / O user device specific key, the session identifier, and the address of the user terminal emulation application 110 to the first I / O user device 130 .

[0138] At least one EAP message may be sent 506b to the user terminal emulation application 110 through a secure channel connection using the DIAMETER protocol or the RADIUS protocol. The EAP authenticator 400 exchanges EAP messages between the user tag 101 and the user terminal emulation application 110.

[0139] The EAP authenticator 400 may generate 509 a first I / O user device specific key based on a key derivation function performed on the master key and the identifier of the first I / O user device 130 .

[0140] The EAP authenticator 400 may obtain 513 an identifier of a second I / O user device 130 that is located proximate to the first I / O user device 130 and has I / O user interface capabilities that satisfy the rule for providing a communication service in combination with the I / O user interface capabilities of the first I / O user device 130, and generate 514b a second I / O user device-specific key based on the master key. The EAP authenticator 400 may then send 510 the second I / O user device-specific key, the session identifier, and an address for the user terminal emulation application 110 to the second I / O user device 130.

[0141] The corresponding operation of the first I / O user device 130 is now described. The first I / O user device 130 may include at least one processor 1100 ( Figure 7 ) and at least one memory 1110 (which stores program codes executable by at least one processor to perform operations Figure 7 ). The operation includes receiving 502 an attachment request from a user tag and forwarding 503 the attachment request to the authenticator 400. The operation forwards 504 an identity request received from the authenticator 400 to the user tag and forwards 505 a response received from the user tag to the authenticator 400, the response including an identifier of the user tag, the user tag including an address of a user terminal emulation application 110 hosted by the user terminal emulation server 100. The operation receives 510 a message from the authenticator 400, the message including a first I / O user device specific key for the first I / O user device 130, a session identifier, and an address for the user terminal emulation application 110. The operation establishes 511 a secure channel connection with the user terminal emulation application 110 using the first I / O user device specific key and the session identifier received from the authenticator 400. The operation sends 512 an indication of the I / O user interface capabilities of the first I / O user device to the user terminal emulation application 110 over the secure channel connection. The operation communicates 512 with the user terminal emulation server 100 to provide at least a portion of the communication service to the user using the I / O user interface capabilities of the first I / O user device 130 .

[0142] The operation of establishing a 511 secure channel connection with the user terminal emulation application 110 using the first I / O user device specific key and session identifier received from the authenticator 400 may include sending the session identifier and the identifier of the first I / O user device to the user terminal emulation application 110 to indicate which I / O user device specific key will be used to establish the 511 secure channel connection.

[0143] The first I / O user device 130 may include a near field communication NFC reader circuit configured to power the user tag to send 502 an attach request.

[0144] Utilizing authorization tokens and related operations are now discussed below.

[0145] In the above operation 508, when the user tag 101 has authenticated itself to the EAP server / user terminal emulation application 110 using EAP, the user tag 101 now also possesses the session keying material. Using the session keying material, the user tag 101 can generate authorization tokens for other IODs (e.g., IOD X) that the user tag 101 wants to add to the currently ongoing session.

[0146] These operations may be an alternative to having the EAP authenticator 400 or IODH 212 delegate session keys to the I / O user device. The token may be, for example, signed data containing content such as a session ID (so that the EAP server / user terminal emulation application 110 can map the token to the session), the newly selected I / O user device identity (so that the EAP server / user terminal emulation application 110 can verify that the correct I / O user device is using the token), and possibly the lifetime of the token.

[0147] The user tag 101 may provide such a token (and a pointer to the EAP server / user terminal emulation application 110) to the selected I / O user device, which may then connect to the EAP server / user terminal emulation application 110 and present the token as proof of authorization by the user tag 101. The communication between the user tag 101 and the newly selected I / O user device may be similar to the initial registration with the IOD domain 410 beginning with operation 501 as described above; the user tag 101 indicates that it wants to connect the I / O user device 10D X to the EAP server / user terminal emulation application 110, but replies with its identity in a manner that the I / O user device 10D X understands.

[0148] As an example, when providing the identity of the user tag in the EAP identity reply message, the user tag 101 may use the session ID as the identifier (or part of the identifier). The I / O user device 10D X itself or the EAP authenticator 400 may determine the relationship with the already ongoing session based on the identifier, and this will result in providing the identity of the new I / O user device to the user tag 101.

[0149] The identity of the I / O user device can be interpreted as an authentication challenge in the EAP method. The reply to the challenge can be a token generated by the user tag 101. The I / O user device 10D X can use the help of the EAP authenticator 400 to verify that the token is valid (for example, the EAP authenticator 400 has the same keying material and can verify the signature), or can blindly trust the token and start using the token to the EAP server / user terminal emulation application 110.

[0150] When the user needs to select (one or more) I / O user devices to be used, these operations provide the user tag 101 and / or the user with more control over which I / O user device(s) are connected to the session. For the EAP server / user terminal emulation application 110 to have proper trust in the tag, the user tag 101 will also have a signature generated by the permanent credentials of the user tag 101 (or the non-derived keying material of the EAP exchange, i.e., the keying material not shared with the EAP authenticator 400) towards the EAP server / user terminal emulation application 110, because the session key generated by EAP is also known to the EAP authenticator 400, the EAP authenticator 400 can therefore generate a valid-looking token even without the user's knowledge.

[0151] Public IOD domains versus private IOD domains and related operations are now discussed below.

[0152] The operations described above can be used in various scenarios, such as in public places (e.g., resorts / hotels) or private places (e.g., corporate offices / complexes). For these different types of scenarios, there are differences in access control requirements, such as for public places (typically), anyone should be able to connect their cloud services (e.g., user terminal emulation applications 110) to public I / O user devices, while in private settings, only authorized services / users are typically allowed. This can be, for example, that employees of a company are allowed to connect their user terminal emulation applications 110 to I / O user devices in an office building. Alternatively, a hybrid model can be provided in which certain I / O user devices are accessible to anyone, while some other I / O user devices are accessible only to a subset of users and / or user terminal emulation applications 110.

[0153] The controller functions and related operations are now discussed below.

[0154] The controller function in the IOD domain 410 may be responsible for verifying that the connecting user terminal emulation application 110 is authorized to connect to the specified I / O user device. This may be a separate entity or function of the IODH 212, which is aware of all I / O user devices in the domain 410. Alternatively, the controller function may be part of the EAP authenticator 400 or an authentication and key management (AKMA) server for applications, respectively (which in turn may be part of the IODH 212, or a separate entity / function).

[0155] When the user terminal emulation application 110 or the user is authenticating to the AKMA server or EAP authenticator 400, the I / O user device domain controller (IDC) can operate to verify that the identity being connected (the tag identity authenticated with EAP, the user terminal emulation application identity learned when establishing a secure channel to the user terminal emulation application 110 during EAP, or the user terminal emulation application identity learned during AKMA authentication) is authorized to access services in the IOD domain 410, and specifically the target I / O user device. If there is an access control policy indicating that the user and / or the user terminal emulation application 110 is not allowed, the controller function can operate to terminate the authentication and can provide some error code indicating that the user and / or service is not authorized.

[0156] The 3GPP key agreement method and related operations are now discussed below.

[0157] A 3GPP key agreement function for providing communication services to I / O user equipment in the I / O user equipment domain 920 through a user terminal emulation application is now described. Various operations are described in the context of AKMA and GBA, but are not limited thereto. Figure 6 A combined flow chart of operations and related data flows between a user tag, an I / O user device, a 3GPP key agreement function system (which may be an AKMA system or a general bootstrapping architecture system) and a user terminal emulation server 110 according to some embodiments of the present disclosure is illustrated. Fig.10 A flow diagram illustrating operations that may be performed by the user terminal emulation server 110 according to some embodiments is illustrated.

[0158] refer to Figure 6, user 901 selects a target I / O user device 902 and obtains an I / O user device identifier therefrom. For example, the user may scan the I / O user device identifier, such as by scanning a QR code, reading an identifier from a sticker on the I / O user device and entering the identifier into the user's own input device, reading an identifier from the I / O user device using NFC, etc. The user tag and the I / O user device may include circuitry configured to transmit information described herein using one or more communication protocols. The I / O user device identifier may include an identifier (IOD_ID) of the I / O user device and an IOD domain identifier (e.g., screen123@myioddomain.com).

[0159] The user 901 connects 903 to the user terminal emulation application 110 (its own cloud-based service) and authenticates it. The I / O user device or IOD domain can provide a communication connection, such as via Bluetooth, WiFi, NFC, etc., or the user device and / or user tag can be configured with its own communication connection. Once the user terminal emulation application 110 has authenticated the user / tag, the user 901 provides the obtained IOD ID to the user terminal emulation application 110.

[0160] The user terminal emulation application 110 generates mobile subscription / SIM-based credentials for use toward the service by interacting 904 with the AKMA system 900 or the Generic Bootstrapping Architecture (GBA) function in the mobile operator. As a result of the interaction 904, the user terminal emulation application 110 and the mobile operator (e.g., AKMA or GBA function) have a shared master AKMA key or a shared master GBA key, and have an identifier for the context or key.

[0161] The user terminal emulation application 110 connects to the IOD domain (e.g., AKMA server) based on the I / O user device identifier domain portion (e.g., myioddomain.com) (received in operation 903). The user terminal emulation application 110 derives the IOD domain (e.g., AKMA server 910) specific key from the AKMA or GBA master key. The user terminal emulation application 110 provides the IOD domain (e.g., AKMA server 910) with an AKMA or GBA context identifier. The IOD domain (e.g., AKMA server 910) uses the received AKMA or GBA context identifier to obtain the IOD domain specific AKMA or GBA key from the mobile operator AKMA or GBA function (e.g., AKMA server 910), which may require a pre-existing SLA / trust relationship between the IOD domain and the mobile operator hosting the AKMA system. The user terminal emulation application 110 and the IOD domain (e.g., AKMA server 910) authenticate using the IOD domain specific AKMA or GBA key, which can use the created secure session for further communication.

[0162] The user terminal emulation application 110 informs 905 the IOD domain which I / O user device (e.g., screen 123) it wants to interact with, e.g., based on the I / O user device identifier received in operation 903. The user terminal emulation application 110 also provides a pointer to itself, such as an IP address, FQDN, etc.

[0163] The IOD domain 920 (e.g., AKMA server 910) generates 906 an IOD-specific AKMA or GBA session key based on the IOD domain-specific AKMA or GBA key and the I / O user device identity (this can be similar to how the IOD-specific key is derived from the EAP PMK in the above-mentioned EAP example), and provides the IOD-specific key to the I / O user device. The IOD domain 920 (e.g., AKMA server 910) may also provide a pointer to the user terminal emulation application 110 and an AKMA or GBA context identifier.

[0164] The I / O user device is connected 907 to the user terminal emulation application 110 based on the received information. The I / O user device indicates an AKMA or GBA context identifier to the user terminal emulation application 110. The user terminal emulation application 110 can locate an AKMA or GBA context (e.g., an AKMA or GBA master key). The I / O user device indicates its identity to the user terminal emulation application 110. The user terminal emulation application 110 can use the I / O user device identity and the IOD domain specific AKMA or GBA key to derive the IOD specific AKMA or GBA session key. The user terminal emulation application 110 and the I / O user device can use the I / O user device specific AKMA or GBA session key to authenticate each other. The user terminal emulation application 110 and the I / O user device can further establish a secure channel between them using a key for streaming data for communication services.

[0165] refer to Fig. 9 The operation of the user terminal emulation server 100 may more generally include authenticating 903 a user tag or an identifier of a user, receiving 903 an identifier of a first I / O user device, and generating 904 and 905 a first I / O user device specific key by communicating with a 3GPP key agreement function.

[0166] The key agreement function may include one of: AKMA function; GBA function; and battery efficient security for very low throughput machine type communication function.

[0167] The operations for generating 904 and 905 the first I / O user device specific key by communicating with the key agreement function may include generating the first I / O user device specific key based on processing a master key derived by the key agreement function.

[0168] The operations may also include communicating with a 3GPP key agreement function (eg, AKMA function) hosted in the mobile operator system to generate a shared key between the user terminal emulation server 100 and the key agreement function.

[0169] An example I / O user device, user terminal emulation server, EAP authenticator or AKMA server, user tag, and mobility manager are now discussed below.

[0170] Figure 71 is a block diagram of a hardware circuit component 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 1102, a near field communication circuit 1120, at least one processor circuit 1100 (processor) and at least one memory circuit 1110 (memory). The processor 1100 is connected to communicate with other components. The memory 1110 stores program code (e.g., (one or more) user terminal emulation applications 110) executed by the processor 1100 to perform the operations disclosed herein. The processor 1100 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 1100 is configured to execute program code in the memory 1110 described below as a non-transitory computer-readable medium to perform some or all of the operations and methods for one or more embodiments disclosed herein for mobile electronic devices. The I / O user device 130 may include one or more UI component devices, including but not limited to a microphone 1140 , a speaker 1150 , a camera 1130 , a display device 1160 , and a user input interface 1170 .

[0171] Figure 8 1 is a block diagram of hardware circuit 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 1250, a database 120 (e.g., any one or more of a list of I / O user devices, UI capabilities of the I / O user devices, a communication protocol for communicating with the I / O user devices, a known proximity to a user identifier, an identifier of a user tag, an I / O user device-specific key, a session identifier, etc.), a display device 1230, a user input interface 1240 (e.g., a keyboard or a touch-sensitive display), at least one processor circuit 1200 (processor) and at least one storage circuit 1220 (memory). The processor 1200 is connected to communicate with other components. The memory 1220 stores (one or more) user terminal emulation applications 110 executed by the processor 1200 to perform the operations disclosed herein. The processor 1200 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 1200 is configured to execute computer program instructions in the memory 1220 hereinafter described as a non-transitory computer-readable medium to perform some or all of the operations and methods for one or more embodiments disclosed herein for a mobile electronic device.

[0172] Fig. 9A block diagram of hardware circuit components of an EAP authenticator 400 or an AKMA server 910 configured to operate according to some embodiments of the present disclosure is illustrated. The components may include a wired / wireless network interface circuit 950, a display device 960, a user input interface 970 (e.g., a keyboard or touch-sensitive display), at least one processor circuit 930 (processor) and at least one memory circuit 940 (memory). The processor 930 is connected to communicate with other components. The memory 940 stores program instructions executed by the processor 930 to perform the operations disclosed herein. The processor 930 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 930 is configured to execute computer program instructions in the memory 940 described below as a non-transitory computer-readable medium to perform some or all of the operations and methods for one or more embodiments disclosed herein for mobile electronic devices.

[0173] Fig.10 A block diagram of a hardware circuit component of a user tag 101 configured to operate according to some embodiments of the present disclosure is illustrated. The component may include a wired / wireless network interface circuit 1050, 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 1020 (memory). The processor 1000 is connected to communicate with other components. The memory 1020 stores program instructions executed by the processor 1000 to perform the operations disclosed herein. The processor 1000 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 1000 is configured to execute computer program instructions in the memory 1020 described below as a non-transitory computer-readable medium to perform some or all of the operations and methods for one or more embodiments disclosed herein for mobile electronic devices.

[0174] Systems and operations for managing mobility of communication services across I / O user devices are now discussed below.

[0175] Some further embodiments of the present disclosure are directed to providing a mobility manager responsible for managing mobility of communication services across I / O user devices in response to user tags carried by users and / or mobility of I / O user devices.

[0176] Fig.11A block diagram of hardware circuit components of a mobility manager 1260 configured to operate according to some embodiments of the present disclosure is illustrated. The components may include a wired / wireless network interface circuit 1150, a display device 1130, a user input interface 1140 (e.g., a keyboard or touch-sensitive display), at least one processor circuit 1100 (processor), and at least one memory circuit 1120 (memory). Although the components of the mobility manager 1260 are illustrated separately from the components of the user terminal emulation server 100, some or all of the functions of the mobility manager 1260 may be incorporated into the user terminal emulation server 100. The processor 1100 is connected to communicate with the other components. The memory 1120 stores program instructions executed by the processor 1100 to perform the operations disclosed herein. The processor 1100 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 1100 is configured to execute computer program instructions in the memory 1120 hereinafter described as a non-transitory computer-readable medium to perform some or all of the operations and methods for one or more embodiments disclosed herein for a mobile electronic device.

[0177] Before discussing the details of mobility management according to some embodiments of the present disclosure, an overview of 3GPP-based mobility management and related Bluetooth and WiFi headset mobility is discussed.

[0178] Example 3GPP mobility management may include the following operations.

[0179] Event A3 is triggered when a neighbor cell becomes better than a special cell (SpCell) by an offset. A special cell is a primary serving cell of a master cell group (MCG) or a secondary cell group (SCG). The offset can be positive or negative. Measurement report management for LTE is described in Section 5.5 of 3GPP TS 36.331 Version 17 V17.1.0. Measurement report management for NR is described in Section 5.5 of 3GPP TS 38.331 Version 17 V17.1.0.

[0180] This event is typically used for intra-frequency or inter-frequency handover procedures. When event A2 is triggered, the UE can be configured with measurement gaps to measure inter-frequency objects and event A3 for inter-frequency handover. Event A3 provides a handover triggering mechanism based on relative measurement results, for example, it can be configured to trigger when the reference signal received power (RSRP) of the neighbor cell is stronger than the RSRP of the serving cell.

[0181] The trigger and cancel conditions are as follows:

[0182] ·Mn + Ofn + Ocn - Hys > Mp + Ofp + Ocp + Off (Trigger condition)

[0183] ·Mn + Ofn + Ocn + Hys < Mp + Ofp + Ocp + Off (Cancellation condition)

[0184] For example, consider that the A3 offset is set to 3 dB, and hys, Ofn, Ofp, and Ocp are set to 0 dB. Once the UE discovers any neighbor cell whose measurement is 3 dB better than the serving cell, it should report event A3; for example, the neighbor cell RSRP = -78 dBm and the serving cell RSRP = -82 dBm, where the neighbor cell is better and meets the event offset, so the UE will report event A3 to the gNB.

[0185] In the above trigger condition and cancellation condition, the terms have the following meanings:

[0186] Mn is the measurement result of the neighbor cell without considering any offset.

[0187] Ofn is the measurement object specific offset of the reference signal of the neighbor cell, that is, the offsetMO defined within the measObjectNR corresponding to the neighbor cell.

[0188] Ocn is the cell specific offset of the neighbor cell, that is, the cellIndividualOffset defined within the measObjectNR corresponding to the frequency of the neighbor cell, and is set to zero if not configured for the neighbor cell.

[0189] Mp is the measurement result of the SpCell without considering any offset.

[0190] Ofp is the measurement object specific offset of the SpCell, that is, the offsetMO defined within the measObjectNR corresponding to the SpCell.

[0191] Ocp is the cell specific offset of the SpCell, that is, the cellIndividualOffset defined within the measObjectNR corresponding to the SpCell, and is set to zero if not configured for the SpCell.

[0192] Hys is the hysteresis parameter for this event, that is, the hysteresis defined within the reportConfigNR.

[0193] Off is the offset parameter for this event, that is, the a3-Offset defined within the reportConfigNR.

[0194] Mn, Mp are expressed in dBm in the case of RSRP, or in dB in the case of RSRQ and RS-SINR

[0195] The relevant uplink-based switching process may include the following operations.

[0196] Many approaches have been offered in previous evolutions of mobile systems. There are several explanations as to why downlink reference symbol based solutions were adopted, one of which is the historical lack of high capacity BS-BS and later NodeB-NodeB and later eNB-eNB fiber connections that would have enabled joint uplink “base station” reception. While today’s solutions have Gigabit gNB-gNB connections, these approaches are challenged by downlink based approaches due to the “must have” for systems to be backward compatible.

[0197] A recent proposal to migrate LTE to UE-transmitted UL SRS-based mobility involves the UE transmitting the UL RS received at the serving BS and possibly several neighbor BSs (n-BS), allowing the network to perform UL signal strength measurements. These measurements are processed in a central network controller to make intelligent proactive decisions about which BS will serve a given user. Implementation of the UL-HO scheme requires that the time synchronization between the BSs receiving the UL RS should be within some specified upper limit.

[0198] This requirement may already be in place to efficiently support other implementations in small cell deployments with very short propagation times, such as TDD operation, joint uplink transmission, etc. In addition, in order to enable n-BS, the configuration parameters (timing, frequency, code, etc.) of such UL RS set by s-BS are also shared with n-BS. This can be efficiently implemented via existing interfaces (such as X2 or S1 in LTE) and will only require some minor standard upgrades in defining the information elements to be communicated between BSs.

[0199] From a power control perspective, it should be noted that the n-BS only needs to detect and measure the UL RS when the UE is close to the cell border, i.e. in the event of a handover. When this happens, the power control set by the s-BS should allow the UL RS to be received at the n-BS, since both the s-BS and the n-BS become almost equidistant (in radio terms).

[0200] Furthermore, the detection of UL RS is quite robust since, by design, it is a known signal transmission with known time, frequency and code signature and is therefore easily detectable and measurable at the n-BS. The rest of the handover (HO) procedure remains the same as in LTE and NR starting from the HO preparation phase. By reusing the UL channel measurements from UL RS also for mobility purposes (e.g. required in massive MIMO operation), no additional signaling overhead is required. Another benefit of using UL measurements for UE mobility is that it is possible to improve network performance through network-side upgrades without affecting the UE.

[0201] The network controller measurement process can include the case where the serving BS becomes weaker than the target BS as the UE moves through the network. When the serving BS and the n-BS detect and measure the UL RS, UL RS received power (UL-RSRP) measurements also need to be performed, and these measurements are processed in the central network controller. If the UL-RSRP of the serving BS is less than the target BS by an offset called the "A3 UL-Offset" and this state is maintained during the time defined by the "UL Trigger Time (UL-TTT)", the controller decides which BS will serve the given UE. Based on the controller HO decision, the serving BS sends a HO request to the target BS recommended by the controller.

[0202] Example Bluetooth and WiFi headset mobility management may include the following operations.

[0203] Wi-Fi access point mobility is typically device-centric, where a (proprietary, chipset-specific) algorithm detects channel signal strength (quality) and evaluates whether a channel offered from one access point at a certain channel (e.g., 1,6,11 as orthogonal for 801.22b / g) offers better signal strength than some other access point. If this is determined to be the case, the device must stop the connection for the previous access point (i.e., interrupt application data flow) and resume communications at the new access point after the traditional steps of authentication, association, and handshake.

[0204] There are management solutions where the network controller node(s) support selection, packet forwarding, and grouping of Wi-Fi nodes in a more cellular manner.

[0205] Wi-Fi mobility is downlink centric, where access points send beacon signals for devices to measure and determine mobility based on that.

[0206] We now describe an attempt to extend 3GPP, Bluetooth or WiFi mobility management to Figure 1-6 Some problems that may arise in the case of system architecture.

[0207] 3GPP mechanisms are unable to address the mobility challenges experienced as they are all based on downlink reference symbol detections sent by the e / gNB measured and evaluated by the UE and reported to the serving UE-e / gNB.

[0208] The 3GPP solution also only addresses the scenario where the UE moves between different e / gNBs, rather than the following scenario: a non-3GPP user-defined minimalist device (user tag 101) operating, for example, via NFC, active / passive RFID or Bluetooth moves between communicating with different UEs (I / O user equipment 130).

[0209] The control-data plane in the traditional solution is terminated in the UE, while Figure 1-6 In the architecture, the control plane terminates in the user tag and the data plane terminates in the associated I / O user device 130.

[0210] Previous mechanisms do not manage mobility based on providing certain UI capabilities among (one or more) I / O user devices 130 for communication services to be provided or being provided to the user, and attempting to maintain the continuity of UI capabilities when performing handovers between I / O user devices 130. For example, the disaggregated paradigm provided by current e / gNB-centric solutions cannot manage UI capabilities (media types) and provide UI continuity for communication services.

[0211] Various embodiments of the present disclosure relate to the operation of a mobility manager that manages the mobility of a user tag relative to a user's relative (e.g., radio measurement-based) location and current user state (e.g., idle / active communication state) when communicating with an I / O user device, and selects and manages session media mobility in the latter. The mobility manager may be responsible for processing the content of user tag beacon signal data, beacon signal filtering, beacon signal strength / threshold evaluation, and responsive application of mobility procedures.

[0212] In previous mobility paradigms, UE mobility is managed between e / gNBs, where: reference signals are sent by e / gNB (DL) or UE (SRS, UL); mobility principles are enforced by e / gNB or radio network control nodes; and both the user (data) plane and control plane involved are terminated in the UE. In contrast to these previous mobility paradigms, operations according to various current embodiments involve: the control plane is terminated in a user tag; the user (data) plane is terminated in any I / O user equipment, which in their role simultaneously acts as a reception point for user tag beacon signals, and where the mobility of user tags between I / O user equipment can be managed by a central mobility manager based on the attributes of the user tag beacon signals detected by multiple I / O user equipment.

[0213] Some mobility management operations are now described in the context of a scenario where a user tag (UT) sends a beacon signal containing session related information, which is received by two I / O user devices (IOD A and IOD B) located proximate to the user tag (UT). Fig.12 Mobility scenarios and some related mobility management operations that may be performed by a mobility manager according to some embodiments of the present disclosure are illustrated. Fig.15 A flow chart illustrating operations that may be performed by a user tag according to some embodiments of the present disclosure is illustrated. Fig.16 A flow chart illustrating operations that may be performed by an I / O user device according to some embodiments of the present disclosure is illustrated. Fig.17 A flow diagram illustrating operations that may be performed by a mobility manager according to some embodiments of the present disclosure is illustrated.

[0214] refer to Fig.12 , 15 , 16 and 17, the example user terminal emulation server and IODH 100 have three user terminal emulation applications 110 illustrated as App#1, App#2, App#3, which have been called by the server 100 and are being executed by the server 100. The user tag 101 can be carried by the user and includes a circuit configured to perform communication with the authenticator 400 (via communication through the I / O user device IOD A 130 or IOD B 130 to obtain session related information. Figure 4 ) or 910( Figure 6 ) authentication process 1100. The user tag 101 sends 1502 a beacon signal containing session related information to an I / O user device located adjacent to the user tag 101.

[0215] In some further embodiments, the user tag circuit may be configured to obtain session related information based on an authenticated session identifier obtained through communication with the authenticator 400 for authentication. For example, the user tag circuit may obtain session related information from an EAP response message from the authenticator. The user tag circuit may be configured to receive beacon configuration information from the I / O user device 130 and send a beacon signal at an interval defined based on the beacon configuration information. The user tag circuit may be configured to receive beacon configuration information from the I / O user device 130 and send a beacon signal at a power level defined based on the beacon configuration information. As will be described in further detail below, the user tag circuit may be configured to derive a key based on an authentication process with the authenticator 400 and use the key to send a beacon signal with secure communication protection. These and other related embodiments of user tag operation are described in more detail below.

[0216] IOD A 130 and IOD B 130 are spaced apart in position and receive 1600 a beacon signal sent by the user tag 101 and each respectively measures 1602 the signal strength of the beacon signal to generate a beacon signal measurement. IOD A 130 and IOD B 130 each send 1604 the beacon signal measurement and session related information for use by the mobility manager 1260 to manage mobility of communication services for the user, which may be provided by the user terminal emulation server 100 and / or the IOD H 212. As explained below, the mobility manager 1260 may use the beacon signal measurement to manage mobility of the communication service for one or more of the user terminal emulation applications 110 (App#1, App#2, App#3), such as by triggering a switch of a communication flow being routed to IOD A 130 to be routed to IOT B 130.

[0217] In the illustrated scenario, based on the reported beacon signal measurements, the mobility manager 1260 determines that a user tag uplink IOD-to-IOD event occurs at time event “1”, which is at a received power (P RX 100404 100405 10040608 10040709 10040809 1004090809 10040909 1004080809 100409 ...80809 100409080809 10040909 100409080809 10040909 100409080809 100409080809 10040909 100409080809 100409080809 100409080809 100409080809 100409080809 100409080809 10040908080

[0218] The illustrated subsequent time event "2" corresponds to a user tag IOD-IOD mobility evaluation trigger time (TTT), after which the TTT expires and the mobility manager 1260 determines what kind of IOD-to-IOD mobility to perform.

[0219] The subsequent time event "3" further illustrated corresponds to the mobility manager 1260 initiating mobility of IOD A to IOD B. The mobility manager 1260 performs authentication and IOD flow configuration, IOD B flow ADD (e.g., adding user terminal emulation application details: FQDN, K_IOD_B) to initiate routing of media flows to IOD B, and IOD A flow REMOVE to initiate stopping routing of media flows to IOD A. The ADD decision can be performed by the mobility manager 1260, but the execution of the ADD event can optionally or typically flow through the EAP authenticator and possibly signaled via the IODH 212. For example, the mobility manager 1260 can request the EAP authenticator, or the IODH 212 requesting the EAP authenticator, to add the IOD flow. It is worth noting that these operations can correspond to mobility switching, although other removal actions may be affected by IOD-switching, such as when a new IOD with (one or more) required UI capabilities is detected. In such a case, a longer delay may be required to remove IOD A or the media flow may need to be interrupted. It should also be noted that initiating routing of the media stream to IOD B (i.e., switching IODs) may be delayed until the user is determined to be located proximate to IOD B, such as in response to a camera of IOD B or another local IOD recognizing the presence of a user carrying user tag 101.

[0220] In some further embodiments, the I / O user device (IOD) circuit may be configured to directly or indirectly receive a message containing an instruction for adding an I / O traffic flow associated with the session-related information from the mobility manager 1260, and initiate output and / or input of the contents of the I / O traffic flow associated with the session-related information through at least one I / O user interface of the I / O user device 130 between the I / O user device 130 and the user terminal emulation application 110. The IOD circuit may be configured to receive a message containing an instruction for removing the I / O traffic flow associated with the session-related information from the mobility manager 1260, and stop output and / or input of the contents of the I / O traffic flow associated with the session-related information through at least one I / O user interface of the I / O user device 130 between the I / O user device 130 and the user terminal emulation application 110. The IOD circuit may be configured to generate a beacon signal measurement based on a current measurement of the signal strength of a beacon signal currently received from a user tag in combination with at least one previous measurement of the signal strength of at least one previously received beacon signal from the user tag. The combination of previous measurements of signal strength may include filtering as discussed below.

[0221] In some further embodiments, the operation of the IOD circuitry sending 1604 beacon signal measurements and session-related information to the mobility manager 1260 for mobility management may include sending beacon signal measurements for use by the mobility manager 1260 at periodic intervals of a length of receiving a plurality of beacon signals from a user tag, the plurality of beacon signals being used to generate the beacon signal measurements based on combining measurements of signal strength of the plurality of beacon signals. The IOD circuitry may also be configured to trigger sending the beacon signal measurements for use by the mobility manager 1260 in response to at least a threshold change in the measurement of signal strength over a series of received beacon signals.

[0222] These and other related embodiments of IOD operation are described in further detail below.

[0223] According to some embodiments, mobility management operations may differ depending on whether mobility is performed for an idle user session or an active user session. In an idle session, the user has no traffic to and from the user terminal emulation application 110 and / or the authenticator 400 ( Figure 4 ) or 910( Figure 6 )'s active data stream, although the mobility manager 1260 may be operable to track location and beacon signal measurements for the user tag 101.

[0224] The mobility manager 1260 for managing mobility of a communication service for a user through IOD A and IOD B (I / O user device 130) may include circuitry configured to receive 1700 beacon signal measurements and session related information from IOD A and IOD B. As explained above, the beacon signal measurements indicate signal strength measurements of beacon signals from user tags 101 by the IODs (IOD A or IOD B). In response to determining that a mobility switching rule is satisfied based on a comparison of the beacon signal measurements of IOD A and IOD B, the mobility manager 1260 initiates 1702 a mobility switching of an I / O traffic flow associated with the session related information from being routed between the user terminal emulation application 110 hosted by the user terminal emulation server 100 and IOD A to being routed between the user terminal emulation application 110 and IOD B.

[0225] In some further embodiments, the mobility manager circuitry may be configured to determine 1702 that the mobility switching rule is satisfied for switching the I / O traffic flow to the second I / O user device 130 based on determining that the user interface (UI) capabilities of the second I / O user device 130 are operable to provide the communication service and based on a comparison of beacon signal measurements of the first I / O user device 130 and the second I / O user device 130. The mobility manager circuitry may be configured to further determine 1702 that the mobility switching rule is satisfied for switching the I / O traffic flow to the second I / O user device 130 based on a measurement of a radio channel quality between the radio access network 220 and the first and second I / O user devices 130. Alternatively or additionally, the mobility switching rule may be satisfied for switching based on a measurement of link status, such as whether a link is congested resulting in insufficient bit rate and / or excessive latency, and a comparison of link status between links of the first and second I / O user devices.

[0226] The mobility manager circuit may be configured to determine 1702 that a mobility switching rule is satisfied for switching the I / O traffic flow to the second I / O user device 130 based on determining that the UI capabilities of the second I / O user device 130 can be combined with the UI capabilities of the third I / O user device 130 to satisfy the combined UI capabilities operationally required to provide the communication service, and based on the beacon signal measurements of the first I / O user device 130, the second I / O user device 130, and the third I / O user device 130. The mobility manager circuit may be configured to determine 1702 that a mobility switching rule is satisfied for switching the I / O traffic flow to the second I / O user device 130 based on determining that a sum of the beacon signal measurement of the second I / O user device 130 and the second offset threshold exceeds a sum of the beacon signal measurement of the first I / O user device 130 and the first offset threshold. The mobility manager circuit can be configured to update the database 120 to add the beacon signal measurement and session-related information of the third I / O user device to be associated with the indication of the user UI capability of the third I / O user device based on determining that the beacon signal measurement of the third I / O user device satisfies the database addition rule, wherein the database 120 identifies the network address of the I / O user device and the UI capability of the I / O user device as a candidate for use in providing communication services to the user.

[0227] The mobility manager circuit can be configured to initiate 1702 mobility switching of the I / O business flow by the following operations, wherein the operations include sending a message containing instructions for adding an I / O business flow associated with session-related information to the second I / O user device 130, and sending a message containing instructions for removing the I / O business flow associated with the session-related information to the first I / O user device 130.

[0228] The mobility manager circuitry may be configured to receive beacon signal measurements and session related information for one of the I / O user devices 130 in a message sent by the authenticator 400 in response to the authenticator 400 receiving and successfully authenticating the content of a message from one of the I / O user devices 130. The mobility manager circuitry may be configured to receive the beacon signal measurements and session related information in a message sent by one of the I / O user devices 130, and authenticate the content of the message based on a key obtained from the authenticator 400.

[0229] The mobility manager circuit can be configured to, for each I / O user device in the I / O user devices, generate a filtered beacon signal measurement based on combining a newly received beacon signal measurement with at least one previous beacon signal measurement, and initiate mobility switching of an I / O service flow associated with session-related information from being routed between a user terminal emulation application 110 hosted by a user terminal emulation server 100 and the first I / O user device 130 to being routed between the user terminal emulation application 110 and the second I / O user device 130 in response to determining that a mobility switching rule is satisfied based on a comparison of the filtered beacon signal measurement of the first I / O user device 130 and the filtered beacon signal measurement of the second I / O user device 130.

[0230] These and other related embodiments of mobility manager operations are described in further detail below.

[0231] Reference now Fig.18 Various more general operations of the authenticator are described. As explained above for some embodiments, communications between the user tag 101 and the user terminal emulation application 110 may be routed through the EAP authenticator 400 for authentication. The user tag 101 and the user terminal emulation application 110 may share a first key. The user terminal emulation application 110 provides a second key to the EAP authenticator 400, and the user tag 101 locally derives the same second key from the first key. Based on the second key, the user tag 101 and the EAP authenticator 400 derive (e.g., in addition to other keys) a third key (also referred to as a user tag specific key), which the user tag 101 uses to protect the beacon signals it sends. The EAP authenticator 400 (or IODH 212, if the third key is shared with the IODH 212) uses the third key to verify the beacon signal, where the beacon signal is measured by the I / O user device. The authentication protocol between the user tag 101 and the user terminal emulation application 110 is communicated through the I / O user device acting as an access point, but in at least some embodiments, the I / O user device does not participate in the authentication process.

[0232] refer to Fig.18, the authenticator 400 includes a circuit configured to establish 1800 a key through an authentication process with a user tag 101 via a first I / O user device (e.g., IOD A). The authenticator 400 authenticates 1802 a beacon signal from the first I / O user device (IOD A) based on the key. The beacon signal is accompanied by a beacon signal measurement indicating a signal strength measurement of a beacon signal from a user tag that may be carried by the user by the first I / O user device (IOD A). The beacon signal is protected using the key. In response to the authentication of the beacon signal, the authenticator 400 sends 1804 the beacon signal (at least a portion of the beacon signal) and the beacon signal measurement to a mobility manager 1260 that manages mobility of communication services for the user through IOD A and IOD B and / or other I / O user devices 130. Authenticator 400 sending 1804 the beacon signal may correspond to sending session-related information (eg, a session ID), which may be received from the first I / O user device (IOD A) as part of the beacon signal.

[0233] Fig.13A and 13B Operations for mobility management of active sessions according to some embodiments of the present disclosure are illustrated. Fig.14 The operation for mobility management during idle period according to some embodiments of the present disclosure is illustrated. Fig.13A , 13B In the following description of 14, for simplicity, the term "IOD" refers to "I / O user device". Although the illustrated embodiments mainly relate to the scenario where beacon signal measurements are routed from the IOD to the mobility manager through the EAP authenticator, in some other embodiments, the beacon signal measurements are routed from the IOD to the mobility manager.

[0234] refer to Fig.13A and 13B , the illustrated scenario provides mobility for an active user session, wherein media content provided through a user terminal emulation application session (user terminal emulation application 110) is considered in the mobility assessment to determine a valid target IOD (I / O user device 130). In this scenario, the mobility assessment may forgo the IOD-set selection process before performing an evaluation of the associated user tag reference sequence measurement report provided from the IOD that detected the signal. Fig.14 An idle scene is illustrated. Fig.13A , 13B Similar operations to those illustrated in FIG14 have been labeled with the same reference numerals.

[0235] although Fig.13A and 13BIt is not explicitly illustrated in the figure, but the IOD UI capability can be a composite capability provided by a composite IOD, such as a display connected to a camera, and the corresponding "IOD-set" can include UI individual or combined (composite) capabilities (such as camera, display, microphone, speaker, etc.) and also include corresponding UI capability entries (such as camera-screen, microphone-speaker, camera-screen-speaker).

[0236] In the context of mobility management, the illustrated scenario of the control plane functionality terminates in the user tag and the user (data) plane terminates in any IOD.

[0237] In some embodiments, the control plane terminates somewhere other than the user tag. In some embodiments, a user using an IOD to access a user terminal emulation application service (via a user terminal emulation application) can configure what IOD UI capability type is needed, and then have the user terminal emulation application take action based on the configuration and request the appropriate IOD from the IODH 212 (user terminal emulation server 100). The IODH 212 or user terminal emulation server 100 coordinates the selection of the appropriate IOD for the session (based on the defined UI capability requirements), selecting an IOD based on being located adjacent to the user or otherwise in the right location based on beacon signal strength measurements, such as IOD addition controlled by the network / user terminal emulation application 110.

[0238] refer to Fig.13A and 13B In the active session scenario, the user tag ("Usertag") communicates through IOD A to exchange information with the EAP authenticator and the user terminal emulation application to perform the above-mentioned Figure 5 The authentication operation may include the user tag sending a user tag attachment request, receiving a user tag identity request, and providing a user tag identity response.

[0239] "Session Beacon": The beacon may carry an authenticated session ID, such as sessionID.sequence@MAC, where MAC=base64(HMAC(K,sessionID|sequence))(MAC=base64(HMAC(K,sessionID|sequence))). The beacon signal may be a plain session ID based "identity" as described above. Alternatively, the session ID based identity may be carried as an identity in an EAP identity response message. Thus, when there is no association, the beacon signal broadcasts an EAP identity response message with the user tag actual identifier (ID) (e.g., user@user terminal emulation application), which may trigger authentication to the user terminal emulation application via the IOD domain as described above. However, when there is an available association and session, the EAP identity response may carry a session ID based identity. The term K may be a shared key known to the user tag and the EAP authenticator / IODH, such as a PMK or a key derived from the PMK. Sequence is a wrapping sequence number, for example 32 bits long, where K may be regenerated when the sequence is wrapped and incremented for each broadcast.

[0240] According to various embodiments, the user tag sends 1300 a user tag "Ref Seq" ("reference sequence") corresponding to a beacon signal. IOD A receives and measures the beacon signal in operation "IOD UT-RS measurement" and reports 1312 the beacon signal measurements to the EAP authenticator in operation "IOD UT-RS measurement reporting". The EAP authenticator authenticates the beacon, for example based on the "third key" discussed above, and when properly authenticated, relays 1314 the beacon and the accompanying beacon signal measurements to the mobility manager. The EAP authenticator may authenticate (verify) the beacon signal measurements based on, for example, security established and used between the EAP authenticator and IOD A. The beacon signal measurements may correspond to PwrRefSeqUT for the user tag "reference sequence" or "session beacon", where "session beacon": session related information, and where the beacon signal also carries an authenticated session ID. The processing or user tag beacon signal measurement process may include performing IOD user tag-RS measurement reports, including PwrRefSeqUT for UT "reference sequence" or "session beacon". The EAP authenticator may authenticate the reporting of beacon signal measurements based on, for example, infrastructure security (such as long-term security configuration in the IOD domain). In addition, the EAP authenticator may authenticate or verify the beacon itself, such as based on a MAC as described above.

[0241] Similarly, according to various embodiments, the user tag continues to repeatedly (e.g., periodically or aperiodically) transmit 1320 the user tag "Ref Seq" corresponding to the beacon signal. Alternatively, each of the IODs (IOD A, IOD B, and IOD C) may receive the same beacon signal, such that in the following description of the user tag "Ref Seq", the user tag "Ref Seq" may be transmitted to the user tag 1320 in response to the beacon signal. Fig.13A The operations for IOD B are performed in parallel with the operations of IOD A and IOD C. IOD B receives and measures beacon signals in operation "IOD UT-RS measurement" and reports 1322 the beacon signal measurements to the EAP authenticator in operation "IOD UT-RS measurement report". The EAP authenticator authenticates the beacon signal measurements and, when properly authenticated, relays 1324 the beacon signal measurements to the mobility manager. The beacon signal measurements may correspond to PwrRefSeqUT for a user tag "reference sequence" or "session beacon", where "session beacon": session related information and where the beacon signal also carries an authenticated session ID. Processing or user tag beacon signal measurement procedures may include performing an IOD user tag-RS measurement report, including a PwrRefSeqUT for a UT "reference sequence" or "session beacon".

[0242] Similarly, according to various embodiments, the user tag continues to repeatedly (e.g., periodically or aperiodically) transmit 1330 a user tag "Ref Seq" corresponding to the beacon signal. Alternatively, as explained above, each of the IODs (IOD A, IOD B, and IOD C) may receive the same beacon signal. IOD C receives and measures the beacon signal in an operation "IOD UT-RS Measurement" and reports 1332 the beacon signal measurement to the EAP authenticator in an operation "IOD UT-RS Measurement Report". The EAP authenticator authenticates the beacon signal measurement and, when properly authenticated, relays 1334 the beacon signal measurement to the mobility manager. The mobility manager receives the IOD UT-RS Beacon Signal Measurement Report, which may contain a PwrRefSeqUT for a UT "Reference Sequence" or "Session Beacon", and where a "Session Beacon" may be session related information such as a session ID.

[0243] When the session state is active, the mobility manager may determine a new / next IOD (target IOD) and set 1340 the targetIODset to a member of the target UI capability (i.e., IOD A, IOD B, and / or IOD C). The mobility manager may send a message IOD flow ADD to the selected one or more IODs of the IODs (e.g., IOD A, IOD B, and / or IOD C) to which the flow is being switched, and wherein the ADD message may include the user terminal emulation application details: FQDN, K_IOD_<this_IOD> , stream ID. The message sent directly or indirectly to the (one or more) IODs being added may include information identifying the old / source IOD to enable the use of a distributed media stream routing scheme. The mobility manager may also send a message IOD stream REMOVE to one or more current IODs being used to receive or generate streams for an active session and trigger the one or more current IODs to stop receiving or sending streams and be removed from the session.

[0244] The user terminal emulation application may be provided with IOD flow movement information, such as source IOD target IOD, and associated authentication and IOD flow configuration for the new or next IOD.

[0245] For active user sessions, mobility management evaluation 1350 may be performed within (e.g., for) a set of IODs with capabilities currently in use (also referred to as TargetIODset). The operation may determine SourceIODUI capabilities and determine the TargetIOD set based on matching the functionality of the SourceIOD capabilities with the TargetIOD capabilities of potential TargetIODs for providing IOD UT-RS measurement reports and selecting the TargetIOD set from IOD@(capability == SourceIOD capability). For evaluation of user tag IOD to IOD mobility (UT IOD_IOD), the operation may consider ReceivePowerEvaluation(PwrRefSeqUT@sourceIOD, PwrRefSeqUT{ii}@IOD_TargetIODset{ii}). The term PwrRefSeqUT{ii}@IOD_TargetIODset{ii} corresponds to IOD UT-RS beacon signal measurement reports. Beacon signal measurement report values ​​may be filtered, as will be described in further detail below. The mobility evaluation can be based on the ReceivePowerEvaluation(PwrRefSeqUT@sourceIOD,

[0246] Execute using PwrRefSeqUT{ii}@IOD_TargetIODset{ii}).

[0247] When M_UT_IOD_target + Offset_target_IOD - Hyst > M_UT_IOD_source + Offset_source_IOD + Offset, the UT IOD-IOD mobility event can be triggered.

[0248] When M_UT_IOD_target + Offset_target_IOD + Hyst < M_UT_IOD_source + Offset_source_IOD + Offset, the UT IOD-IOD mobility event can be cancelled.

[0249] The target IOD for the user label can select 1350 and 1352 according to the TargetIOD obtained from TargetIODset. A 1354 message can be generated for "IOD stream ADD" for the determined (selected) next IOD (TargetIOD). And a corresponding other message for "IOD stream REMOVE" can be generated for the determined (selected) previous IOD (SourceIOD). The IOD data stream routing and termination operations can include sending the IOD stream ADD message directly or indirectly to the next IOD (such as IODB), and sending the IOD stream REMOVE message to the previous (old) IOD (such as IOD A). The user terminal emulation application / EAP server can operate to remove the IOD stream for the source IOD A at 1360.

[0250] In Fig. 13B and 14 the mobility manager operates to add (ADD) the target IOD, for example, via the step of generating messages 1354 and 1400 for "IOD stream ADD" for the determined (selected) next IOD (TargetIOD). Alternatively, the operation for adding the target IOD (such as IOD B) can include the mobility manager notifying the EAP authenticator to add the target IOD to the identified stream. The EAP authenticator can provide the addition information to the target IOD. For example, in the example context of Figure 5 the EAP authenticator 400 can receive from the mobility manager ( Fig.13A ) related to Figure 5The notification message corresponding to step 514A in step 514A is sent to the target IOD (eg, IOD B) and the IOD flow ADD message is sent. The mobility management can still send the IOD flow REMOVE message to the previous old IOD (eg, IOD A).

[0251] although Fig.13A and 13B Mainly related to active session scenarios, but when the session state is idle, the mobility manager can set 1340 TargetIODset to "any". For idle user sessions, IOD mobility evaluation can be performed similarly, but within the set of any IOD detected via IOD UT-RS measurement reports and verified valid by the EAP authenticator. Therefore, operations for UI capability matching for services are unnecessary. In operation 1400, the mobility manager can add the target IOD to the set (targetIOD ADD) and can remove the source IOD from the set (sourceIODREMOVE).

[0252] The operation of the EAP authenticator may include deriving a key for protecting the identity carried in the user tag beacon signal, such as a key used in HMAC. This may be based on the PMK. The EAP authenticator may be utilized in two different ways, depending on how the beacon is carried.

[0253] According to the first approach, if the beacon signal carries only a common session ID-based identity, the EAP authenticator does not participate in the mobility event except for generating user tag specific keys. However, the EAP authenticator derives the key to be used for the beacon HMAC and provides it to the IODH so that the IODH can verify the beacon signal.

[0254] According to the second approach, if the beacon signal carries the session ID and other data as an identifier in the EAP identity response message, the IOD can forward the beacon / identity response to the EAP authenticator or to the mobility manager (e.g., IODH). If forwarded to the mobility manager (e.g., IODH), the EAP authenticator will not play any further role except when the beacon signal is just an identity based on a normal session ID. Therefore, the remaining description of the EAP authenticator is for the scenario where the beacon carries the EAP identity response message, which is forwarded by the IOD to the EAP authenticator.

[0255] The EAP authenticator communicates with the mobility manager (e.g., IODH) and provides the mobility manager (e.g., IODH) with the verified beacon (e.g., verifying the MAC of the session ID-based identifier carried by the EAP message, etc.) together with the signal strength reported by the IOD, so that the mobility manager (e.g., IODH) can use the information to make mobility management decisions, etc. When the beacon signal is only a beacon based on a common session ID, the EAP authenticator generates an IOD-specific key according to a request from the IODH, and provides the key and other relevant information to the target IOD (directly or via the IODH).

[0256] The EAP authenticator may optionally forward communications between the mobility manager (eg, IODH) and the user terminal emulation server.

[0257] The IODH or mobility manager receives beacon reports from the IOD, which include beacon and signal strength, etc. The EAP authenticator sends the IOD specific key, the user terminal emulation application FQDN, the session ID, and information about which flow the (target) IOD should request from the user terminal emulation application, such as information identifying the flow currently being sent to the source IOD. This can be sent directly by the EAP authenticator, or via a mobility manager (e.g., IODH).

[0258] The EAP Authenticator verifies the authenticity of the received beacon identifier by verifying the MAC, derives the key for the IOD based on the PMK and the IOD identifier (provided by IODH or the Mobility Manager), and updates the User Tag Beacon Signal Protection Key based on a KDF known to the User Tag (UT) and the EAP Authenticator when the sequence number is wrapped.

[0259] The user terminal emulation application / EAP server communicates directly or indirectly (e.g., via an EAP authenticator) with a mobility manager (e.g., IODH) to optionally receive IOD flow movement information (e.g., source IOD, target IOD). The user terminal emulation application / EAP server also communicates with the IOD. The target IOD authenticates the user terminal emulation server and indicates that the flow currently being sent to the source IOD should be moved to the target IOD. The user terminal emulation server can verify this with information optionally received from the mobility manager (e.g., IODH). The user terminal emulation application / EAP server performs rerouting of the flow from the source IOD to the target IOD.

[0260] Some further embodiments relate to operations for performing IOD-to-IOD mobility assessment based on user tag beacon signal strength measurements.

[0261] The IOD or mobility manager / IODH may apply filtering to the beacon signal strength measurement data before the data is used to evaluate whether any mobility triggering events have occurred at the user tag layer (eg, whether a handover or other mobility rule has been satisfied).

[0262] The filtering may be based on conventional 3GPP L3 filtering procedures, where the filtering is performed by the IOD or mobility manager / IODH rather than by the e / gNB.

[0263] In some embodiments, the filter function is based on the following equation:

[0264] Fn=(1-a)*Fn-1+(a*MEASn),

[0265] Where Fn = updated filtered measurement result,

[0266] Fn-1 = previous filtered measurement,

[0267] a=(1 / 2) k / 4 , where k is the filter coefficient, chosen by the mobility manager / IODH, and

[0268] MEASn = latest measurement received from UT via source / destination IOD.

[0269] The latest measurement result MEASn may be based on {M_UT_IOD_target, M_UT_IOD_source}.

[0270] Depending on the architectural choices, it may be advantageous for the mobility manager / IODH to perform the filtering.

[0271] In some applications with capable IODs and filtering is based on parameters obtained from the mobility manager / IODH, the IOD may employ filtering and, for example, utilize relaxed / hysteresis-based less frequent IOD measurement reporting to the mobility manager / IODH.

[0272] The user tag IOD-IOD mobility event can be configured to be triggered when an IOD beacon signal measurement report (from a first IOD) becomes better than another IOD beacon signal measurement report (from a second IOD) by a predefined offset value during a preset time period (trigger time, TTT). The offset value can be positive or negative, and the offset value and TTT can be defined for each individual IOD. In some embodiments, the user tag IOD-IOD mobility event is triggered when the following conditions are met:

[0273] M_UT_IOD_target+Offset_target_IOD-Hyst>M_UT_IOD_source+Offset_source_IOD+Offset.

[0274] In some embodiments, when during the "trigger time", the user tag received beacon signal power detected at one (neighbor) IOD becomes worse than the user tag received beacon signal power detected at the current (source) IOD by a (desirably IOD-specific) offset, the user tag IOD-IOD mobility event is cancelled. In some embodiments, the UT IOD-IOD mobility event is cancelled when the following conditions are met:

[0275] M_UT_IOD_target+Offset_target_IOD+Hyst <M_UT_IOD_source+Offset_source_IOD+Offset,

[0276] in:

[0277] M_UT_IOD_source: signal level or quality or UT received from the source IOD to the management server;

[0278] M_UT_IOD_target: signal level or quality or UT received from the target IOD to the management server;

[0279] Offset: UT IOD-IOD mobility is performed only when the UT signal at the target IOD is significantly better than the UT signal received at the serving (source) IOD;

[0280] Offset_target_IOD: IOD-specific individual offset for target IOD;

[0281] Offset_source_IOD: IOD-specific cell-specific offset for source IOD;

[0282] Trigger time: This timer helps avoid irregular measurements and switching; and

[0283] Hyst: Hysteresis, which is defined in the management node to avoid "ping-pong" regarding mobility between two IODs.

[0284] Some other further embodiments relate to handover (switching), in which the user tag leaves the reception range of the IOD, resulting in the IOD being outside the beacon signal reception capability. The operation may use a trigger decision for handover similar to that discussed above for IOD cell mobility, and may include the use of offsets and hysteresis such as those described above. For example, handover to a no coverage situation is typically associated with other signal strength thresholds, etc., rather than being associated with IOD to other IOD mobility, such as because the impact of a user completely losing coverage is more serious than "perceiving slightly poor quality for a period of time".

[0285] Cloud Implementation

[0286] Some or all of the operations described above as being performed by an I / O user device, a mobility manager, an authenticator, a user terminal emulation server, an EAP authenticator, an AKMA system or server may alternatively be performed by another node that is part of a cloud computing resource. For example, these operations may be performed as network functions close to the edge, such as in a cloud server or cloud resource of a telecommunications network operator, such as in CloudRAN or a core network, and / or may be performed by a cloud server or cloud resource of a media provider (e.g., an iTunes service provider or a Spotify service provider).

[0287] abbreviation:

[0288] 3GPP Third Generation Partnership Project

[0289] App

[0290] BS Base station, such as e / gNB

[0291] BT Bluetooth

[0292] DL Downlink

[0293] EAP Extensible Authentication Protocol

[0294] e / gNB Evolved Node B, Next Generation Node B

[0295] eNB Evolved Node B (also known as RBS, Radio Base Station)

[0296] FQDN Fully Qualified Domain Name

[0297] GW Gateway (also an acronym for Leif GW Persson)

[0298] HO Handover

[0299] ICMP Internet Control Message Protocol

[0300] IOD Input and / or Output Device

[0301] ITU International Telecommunication Union

[0302] KDP key derivation function

[0303] MIMO Multiple Input Multiple Output

[0304] NFC Near Field Communication

[0305] RFID Radio Frequency Identification

[0306] RSRP reference symbol received power

[0307] RTP Real-time Protocol

[0308] RTCP Real-time Control Protocol

[0309] IOD Input Output Device

[0310] IODH Input Output Device Processor

[0311] NTP Network Time Protocol

[0312] S1 Interfaces in 3GPP LTE

[0313] SDP Session Description Protocol

[0314] SR Sender Response

[0315] SRS Sounding Reference Symbol (or Signal)

[0316] TTT Trigger Time

[0317] UE User Equipment

[0318] UL Uplink

[0319] X2 3GPP interface between eNBs in LTE

[0320] Further definitions and embodiments:

[0321] In the above description of various embodiments of the present invention, it will be understood that the terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the present invention. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by those of ordinary skill in the art to which the present invention belongs. It will also be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning consistent with their meaning in the context of this specification and related fields, and will not be interpreted as being specifically defined in this article in an idealized or overly formal sense.

[0322] When an element is referred to as "connected", "coupled", "responded" or its variant to another element, it can be directly connected, coupled or responded to other elements, or there can be intermediate elements. In contrast, when an element is referred to as "directly connected", "directly coupled", "directly responded" or its variant to another element, there is no intermediate element. The same number always refers to the same element. In addition, "coupling", "connection", "response" or its variant used in this article may include wireless coupling, connection or response. As used in this article, the singular form of "one", "an" and "the" is also intended to include plural forms, unless the context clearly indicates otherwise. For the sake of brevity and / or clarity, well-known functions or structures may not be described in detail. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0323] It will be understood that, although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish an element / operation from another element / operation. Therefore, without departing from the teaching of the present invention, the first element / operation in some embodiments may be referred to as the second element / operation in other embodiments. Throughout the specification, the same reference numerals or the same reference numerals represent the same or similar elements.

[0324] As used herein, the terms "comprises," "including," "having," or variations thereof are open ended and include one or more stated features, integers, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integers, elements, steps, components, functions, or groups thereof. In addition, as used herein, the commonly used abbreviation "eg (for example)" derived from the Latin phrase "exempli gratia" may be used to introduce or specify one or more general examples of the aforementioned items, and is not intended to limit such items. The commonly used abbreviation "ie (that is)" derived from the Latin phrase "id est" may be used to specify a specific item from a more general statement.

[0325] Example embodiments are described herein with reference to block diagrams and / or flow charts of computer-implemented methods, devices (systems and / or equipment) and / or computer program products. It will be understood that the blocks in the block diagrams and / or flow charts and the combination of blocks in the block diagrams and / or flow charts can be implemented by computer program instructions executed by one or more computer circuits. These computer program instructions can be provided to processor circuits of general-purpose computer circuits, special-purpose computer circuits and / or other programmable data processing circuits to produce a machine, so that instructions executed by processors of computers and / or other programmable data processing devices, conversion and control transistors, values ​​stored in memory locations, and other hardware components within such circuits implement the functions / actions specified in one or more blocks of the block diagrams and / or flow charts, and thereby create a device (function) and / or structure for implementing the functions / actions specified in (one or more) blocks of the block diagrams and / or flow charts.

[0326] These computer program instructions may also be stored in a tangible computer-readable medium that can instruct a computer or other programmable data processing device to operate in a specific manner so that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions / actions specified in one or more blocks of the block diagram and / or flowchart. Therefore, embodiments of the present inventive concept may be embodied in hardware and / or software (including firmware, resident software, microcode, etc.) running on a processor (such as a digital signal processor), which may be collectively referred to as a "circuit," "module," or variations thereof.

[0327] It should also be noted that, in some alternative implementations, the function / action noted in the frame may occur in an order different from the order noted in the flow chart. For example, depending on the function / action involved, two frames of continuous display can actually be performed substantially in parallel, or these frames can sometimes be performed in reverse order. In addition, the function of a given frame of a flow chart and / or block diagram can be divided into a plurality of frames, and / or the function of two or more frames of a flow chart and / or block diagram can be integrated at least in part. Finally, without departing from the scope of the inventive concept, other frames can be added / inserted between the illustrated frames, and / or frames / operations can be omitted. In addition, although some figures include arrows on the communication path to show the main direction of communication, it will be understood that communication may occur in the direction opposite to the arrows depicted.

[0328] Without substantially departing from the principles of the inventive concept, many changes and modifications may be made to the embodiments. All such changes and modifications are intended to be included in the scope of the inventive concept herein. Therefore, the subject matter disclosed above should be considered illustrative, rather than restrictive, and the examples of the attached embodiments are intended to cover all such modifications, enhancements and other embodiments, which fall within the spirit and scope of the inventive concept. Therefore, to the maximum extent permitted by law, the scope of the inventive concept will be determined by the widest permissible interpretation of the present disclosure, including the following examples of embodiments and their equivalents, and should not be subject to the constraints or limitations of the description detailed above.

Claims

1. A user tag (101) that can be carried by a user and includes a circuit (1000, 1020), wherein the circuit (1000, 1020) is configured to: performing an authentication process with an authenticator (400) via communication through an input and / or output I / O user device (130) to obtain session related information; and A beacon signal containing the session-related information is sent to an I / O user device located adjacent to the user tag.

2. The user tag (101) according to claim 1, wherein: The circuit (1000, 1020) is also configured to: The session related information is obtained based on an authenticated session identifier obtained through communication with the authenticator (400) for authentication.

3. The user tag (101) according to claim 1, wherein: The circuit (1000, 1020) is also configured to: The session related information is obtained from an Extensible Authentication Protocol (EAP) response message from the authenticator.

4. The user tag (101) according to any one of claims 1 to 3, wherein: The circuit (1000, 1020) is also configured to: receiving beacon configuration information from the I / O user device (130); and The beacon signal is transmitted at an interval defined based on the beacon configuration information.

5. The user tag (101) according to any one of claims 1 to 4, wherein: The circuit (1000, 1020) is also configured to: receiving beacon configuration information from the I / O user device (130); and The beacon signal is transmitted at a power level defined based on the beacon configuration information.

6. The user tag (101) according to any one of claims 1 to 5, wherein: The circuit (1000, 1020) is also configured to: deriving a key based on the authentication process with the authenticator (400); and The beacon signal is sent with secure communication protection using the key.

7. An input and / or output I / O user device (130) comprising a circuit (1100, 1110), wherein the circuit (1100, 1110) is configured to: receiving a beacon signal from a user tag (101) that can be carried by a user, the beacon signal containing session related information; measuring a signal strength of the beacon signal to generate a beacon signal measurement; and The beacon signal measurements and the session related information are sent for use by a mobility manager (1260) for mobility management of a communication service for the user, the communication service being capable of being provided by a user terminal emulation server (100) through one or more I / O user devices (130).

8. The I / O user device (130) of claim 7, wherein: The circuit (1100, 1110) is also configured to: receiving a message from the mobility manager (1260) containing instructions for adding an I / O traffic flow associated with the session-related information; and The output and / or input of the content of the I / O service flow associated with the session related information is initiated between the I / O user device (130) and the user terminal emulation application (110) through at least one I / O user interface of the I / O user device (130).

9. The I / O user device (130) according to any one of claims 7 to 8, wherein: The circuit (1100, 1110) is also configured to: receiving a message from the mobility manager (1260) containing an instruction to remove an I / O traffic flow associated with the session-related information; and Outputting and / or inputting the content of the I / O service flow associated with the session related information through at least one I / O user interface of the I / O user device (130) is stopped between the I / O user device (130) and the user terminal emulation application (110).

10. The I / O user device (130) according to any one of claims 7 to 9, wherein: The circuit (1100, 1110) is also configured to: The beacon signal measurement is generated based on a current measurement of a signal strength of a beacon signal currently received from the user tag combined with at least one previous measurement of a signal strength of at least one beacon signal previously received from the user tag.

11. The I / O user device (130) of claim 10, wherein: To send the beacon signal measurements and the session related information to the mobility manager (1260) for mobility management of the communication service for the user, the circuit (1100, 1110) is further configured to: The beacon signal measurements are sent for use by the mobility manager (1260) at periodic intervals of a length of a plurality of beacon signals received from the user tag for use in generating the beacon signal measurements based on combining measurements of signal strengths of the plurality of beacon signals.

12. The I / O user device (130) according to any one of claims 7 to 11, wherein: The circuit (1100, 1110) is also configured to: Responsive to at least a threshold change in a measurement of signal strength over a series of received beacon signals, sending the beacon signal measurements for use by the mobility manager (1260) is triggered.

13. A mobility manager (1260) for managing the mobility of a communication service for a user via an input and / or output I / O user device (130), the mobility manager (1260) comprising a circuit (1100, 1120), the circuit (1100, 1120) being configured to: receiving beacon signal measurements and session related information from a plurality of I / O user devices, the beacon signal measurements indicating signal strength measurements by the I / O user devices of beacon signals from user tags that may be carried by the users; In response to determining that a mobility switching rule is satisfied based on a comparison of the beacon signal measurements of the first I / O user device (130) and the second I / O user device (130), a mobility switching is initiated for an I / O service flow associated with the session-related information from being routed between a user terminal emulation application (110) hosted by a user terminal emulation server (100) and the first I / O user device (130) to being routed between the user terminal emulation application (110) and the second I / O user device (130).

14. The mobility manager (1260) of claim 13, wherein: The circuit (1100, 1120) is also configured to: Based on determining that the user interface UI capabilities of the second I / O user device (130) are operable to provide the communication service, and based on a comparison of the beacon signal measurements of the first I / O user device (130) and the second I / O user device (130), it is determined (1702) that the mobility switching rules are satisfied for switching the I / O service flow to the second I / O user device (130).

15. The mobility manager (1260) of claim 14, wherein: The circuit (1100, 1120) is also configured to: Based on a measurement of a radio channel quality between a radio access network (220) and the first and second I / O user equipment (130) and / or based on a measurement of a link state of the first and second I / O user equipment (130), it is further determined (1702) that the mobility switching rule is satisfied for switching the I / O service flow to the second I / O user equipment (130).

16. The mobility manager (1260) of any one of claims 14 to 15, wherein: The circuit (1100, 1120) is also configured to: Based on determining that the UI capabilities of the second I / O user device (130) can be combined with the UI capabilities of the third I / O user device (130) to meet the combined UI capabilities operationally required to provide the communication service, and based on the beacon signal measurements of the first I / O user device (130), the second I / O user device (130) and the third I / O user device (130), it is determined 1702 that the mobility switching rules are satisfied for switching the I / O service flow to the second I / O user device (130).

17. The mobility manager (1260) of any one of claims 13 to 16, wherein: The circuit (1100, 1120) is also configured to: Based on determining that the sum of the beacon signal measurement and the second offset threshold of the second I / O user device (130) exceeds the sum of the beacon signal measurement and the first offset threshold of the first I / O user device (130), determine 1702 that the mobility switching rule is satisfied for switching the I / O service flow to the second I / O user device (130).

18. The mobility manager (1260) of any one of claims 13 to 16, wherein: The circuit (1100, 1120) is also configured to: Based on determining that the beacon signal measurement of the third I / O user device satisfies the database addition rule, updating the database to add the beacon signal measurement of the third I / O user device and the session-related information as associated with an indication of a user interface UI capability of the third I / O user device, wherein the database identifies a network address of an I / O user device that is a candidate for providing the communication service to the user and the UI capability of the I / O user device.

19. The mobility manager (1260) of any one of claims 13 to 18, wherein: To initiate 1702 a mobility handover of the I / O traffic flow from being routed between the user terminal emulation application (110) and the first I / O user equipment (130) to being routed between the user terminal emulation application (110) and the second I / O user equipment (130), the circuit (1100, 1120) is further configured to: Sending a message including an instruction for adding the I / O service flow associated with the session related information to the second I / O user equipment (130); as well as A message including an instruction for removing the I / O service flow associated with the session-related information is sent to the first I / O user device (130).

20. The mobility manager (1260) of any one of claims 13 to 19, wherein: The circuit (1100, 1120) is also configured to: The beacon signal measurement and the session-related information for one of the I / O user devices (130) are received in a message sent by the authenticator (400) in response to the authenticator (400) receiving and successfully authenticating the contents of a message from the one of the I / O user devices (130).

21. The mobility manager (1260) of any one of claims 13 to 19, wherein: The circuit (1100, 1120) is also configured to: receiving the beacon signal measurements and the session related information in a message sent by one of the I / O user devices (130); and The content of the message is authenticated based on a key obtained from the authenticator (400).

22. The mobility manager (1260) of any one of claims 13 to 21, wherein: The circuit (1100, 1120) is also configured to: for each of the I / O user devices, generating a filtered beacon signal measurement based on combining a newly received beacon signal measurement with at least one previous beacon signal measurement; as well as In response to determining that a mobility switching rule is satisfied based on a comparison of filtered beacon signal measurements of the first I / O user device (130) and filtered beacon signal measurements of the second I / O user device (130), initiating the mobility switching of the I / O service flow associated with the session-related information from being routed between the user terminal emulation application (110) hosted by the user terminal emulation server (100) and the first I / O user device (130) to being routed between the user terminal emulation application (110) and the second I / O user device (130).

23. An authenticator (400) comprising a circuit (930, 940), the circuit (930, 940) being configured to: Establishing a key by an authentication process between a first input and / or output I / O user device (130) and a user tag; authenticating a beacon signal from the first I / O user device based on the key, the beacon being accompanied by a beacon signal measurement indicating a signal strength measurement by the first I / O user device of the beacon signal from a user tag that may be carried by the user; as well as In response to authentication of the beacon signal, the beacon signal and the beacon signal measurements are sent to a mobility manager (1260) that manages mobility of communication services for users through the I / O user device (130).

Images