Method and device for selecting input / output device in wireless communication system

Abstract

A method is provided for enabling adaptation of connectivity to a user tag during an ongoing communication session provided to the user tag by a service via a set of at least one input / output device, in which a preceding beacon signal is transmitted, which is detectable by at least one IOD when a UT is in proximity to the at least one IOD. Upon determining (210) that the adaptation of the set of at least one IOD is required, modifying (220) the preceding beacon signal, where the modifying comprises including to the beacon signal an indication indicating a request for the adaptation of the set of at least one IOD, and transmitting (230) the modified beacon signal, where the modified beacon signal comprises a request for the adaptation of the set of at least one IOD. Thereby enabling one or more IODs located in the vicinity of the UT to participate in the adaptation of the set of at least one IOD.

Description

Technical Field

[0001] The present disclosure relates to selecting an input / output device (IOD) accessed via a user tag (UT) during an ongoing communication session. Background Art

[0002] There are different solutions enabling access to, sharing, and use of hardware resources available in a particular context, room, or network, such as, for example, Apple TV, Sun stateless terminals, or video conferencing systems. However, the commonality of all these solutions is that the user logs in to the corresponding communication system in some way, and the communication devices held by the communication system are defined by the system itself.

[0003] As described in EP 3912312, current solutions for switching, adding, or removing input / output devices (IODs) in a cloud computing context focus on the ability to maintain the IODs throughout the communication session. Advancements in operational characteristics also require higher integration with greater circuit density and faster processing circuits, which becomes more difficult under cost and power consumption constraints.

[0004] Such all-inclusive feature-rich solutions for user terminal development do not meet all of the numerous different expectations held by the consumer side seeking solutions for rapidly expanding various communication services. Additionally, the current societal expectation of always being connected forces users to keep their communication devices readily accessible, or else risk not being able to receive or initiate communication services in a timely manner. Therefore, a more dynamic solution regarding accessibility is needed. Summary of the Invention

[0005] The object of the present disclosure is to at least partially address the above aspects.

[0006] More specifically, according to one aspect, a method in a user tag UT is proposed for enabling adaptation of the connectivity of the UT during an ongoing communication session, wherein the method comprises: during the ongoing communication session, sending a pre-beacon signal, wherein the pre-beacon signal is detectable by at least one IOD when the UT is located near at least one input-output device IOD; when it is determined that adaptation of a set of at least one IOD is needed, modifying the pre-beacon signal, wherein the modification comprises including in the beacon signal an indication indicating a request for adaptation of the set of at least one IOD; and sending the modified beacon signal, such that one or more IODs located near the UT can participate in the adaptation of the set of at least one IOD.

[0007] According to another aspect, a method in an Input / Output Device Handler (IODH) is proposed for adapting the connectivity of a User Tag (UT) during an ongoing communication session, the method comprising: receiving, from a first set of at least one Input / Output Device (IOD), first information in a respective beacon signal associated with the ongoing communication session and received by the respective one or more IODs from the UT; determining an adaptation of the first set of at least one IOD based on second information received from a second set of at least one IOD and included in one or more modified beacon signals; and instructing, based on the determined adaptation, one or more IODs in the first set of at least one IOD how to participate in the adaptation of the first set of at least one IOD.

[0008] According to yet another aspect, a method in a first Input / Output Device (IOD) is proposed for acting in adapting connectivity during an ongoing communication session, the method comprising: receiving a beacon signal associated with the ongoing communication session and sent by a User Tag (UT); determining, at least in part based on the content of the received beacon signal, an indication of whether the received beacon signal is a modified beacon signal, whether the received beacon signal is to be forwarded to an Input / Output Device Handler (IODH) or is to be blocked from forwarding, and, in the case where it is determined that the received beacon signal is a modified beacon signal and at least a portion of the content of the received beacon signal is to be forwarded, forwarding at least a portion of the content of the received beacon signal to the IODH such that the IODH can determine how the first IOD is to act during the adaptation of a set of at least one IOD.

[0009] According to another aspect, a User Tag (UT) is proposed for enabling adaptation of the connectivity of the UT during an ongoing communication session, the UT comprising processing circuitry configured to cause the UT to: send a previous beacon signal during the ongoing communication session, the previous beacon signal being detectable by at least one IOD when the UT is in the vicinity of the at least one IOD; modify the previous beacon signal when it is determined that an adaptation of a set of at least one IOD is required, the modification including including an indication in the beacon signal of a request for adaptation of the set of at least one IOD; and send the modified beacon signal such that one or more IODs in the vicinity of the UT can participate in the adaptation of the set of at least one IOD.

[0010] According to another aspect, an Input / Output Device Handler (IODH) is proposed that is capable of adapting the connectivity of a User Tag (UT) during an ongoing communication session, where the IODH includes a processor circuitry configured to cause the IODH to: receive first information from a first set of at least one Input / Output Device (IOD) associated with the ongoing communication session and received by the respective one or more IODs from the UT in respective beacon signals; determine an adaptation of the first set of at least one IOD based on second information received from a second set of at least one IOD included in one or more modified beacon signals, and instruct one or more IODs among the at least one IOD how to participate in the adaptation of the first set of at least one IOD based on the determined adaptation.

[0011] According to yet another aspect, an Input / Output Device (IOD) is provided that is capable of functioning in adapting connectivity during an ongoing communication session, where the IOD includes a processing circuitry configured to cause the IOD to: receive a beacon signal associated with the ongoing communication session and transmitted by a User Tag (UT); determine, at least in part based on the content of the received beacon signal, whether the received beacon signal is a modified beacon signal, whether the received beacon signal is to be forwarded to an Input / Output Device Handler (IODH), or whether the IOD is to refrain from forwarding the modified beacon signal, and forward at least a portion of the content of the received beacon signal to the IODH in the case where it is determined that the received beacon signal is a modified beacon signal and at least a portion of the content of the received beacon signal is to be forwarded, such that the IODH can determine how the IOD acts during the adaptation of a set of at least one IOD. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Embodiments will now be described in more detail with reference to the drawings, in which:

[0013] Figure 1a is a signaling diagram showing the signaling between a UT, multiple IODs, and an IODH according to one embodiment.

[0014] Figure 1b is a signaling diagram showing the signaling between a UT, multiple IODs, and an IODH according to another embodiment.

[0015] Figure 2 is a flowchart showing a method executable in a UT.

[0016] Figure 3 is a flowchart showing a method executable in an IOD.

[0017] Figure 4 is a flowchart showing a method executable in an IODH.

[0018] Figure 5 is a block diagram showing a UT configured to execute a method according to Figure 2 in accordance with one embodiment.

[0019] Figure 6 is a block diagram showing a UT configured to execute a method according to Figure 2 in accordance with another embodiment.

[0020] Figure 7 is a block diagram showing an IOD configured to execute a method according to Figure 3 in accordance with one embodiment.

[0021] Figure 8 is a block diagram showing an IOD configured to execute a method according to Figure 3 in accordance with another embodiment.

[0022] Figure 9 is a block diagram showing an IODH configured to execute a method according to Figure 4 in accordance with one embodiment.

[0023] Figure 10 is a block diagram illustrating an IODH configured to execute a method according to Figure 4 in accordance with another embodiment. DETAILED DESCRIPTION

[0024] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of the inventive concept are shown. However, the inventive concept may be embodied in many different forms and should not be construed as 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. Components from one embodiment may be appropriately assumed to be present or used in another embodiment.

[0025] The various embodiments disclosed herein relate to a centralized server-based scheme for emulating communication devices by using a collection of networked devices, which may be referred to as input / output (I / O) devices (IODs) or input / output user devices, having combinable functional capabilities to provide a user, when located near the user, with the ability to receive and / or initiate communication services with another communication device via a communication session.

[0026] Some potential advantages of these embodiments include that a user can receive and initiate communication services without the need for traditional fully featured communication devices such as traditional smartphones, mobile phones or tablet computers. A server (which may alternatively be referred to as a management node or orchestrator and is referred to herein as the Input / Output Device Handler IODH) can alternatively adaptively combine the available capabilities of IODs in proximity to the user according to the user's requirements to attempt to provide communication services. The IODH can dynamically respond to incoming communication requests for the user or outgoing communication requests from the user by operatively utilizing or coordinating the available IODs in proximity to the user to form a combined interface through which a user terminal emulation application executed by the server provides user terminal functionality for the requested communication service. Thus, the mentioned server-based solution can provide low-cost, adaptive communication services to the user.

[0027] Whenever an IOD is in proximity to the user, the dynamic allocation of the capabilities of the IOD enables the efficient and flexible use of existing hardware such as, for example, a television, a conferencing device, a laptop computer, a surveillance camera, a connected household appliance, a connected vehicle, a connected ship or a screen, which can provide a functionality referred to as a user interface (UI) to the user during the execution of a communication service. Thus, the user has reduced or eliminated the need to carry an expensive and fully featured user terminal such as, for example, a smartphone, which includes all the necessary UI capabilities, a display device, a keyboard, speakers, etc. The user can alternatively carry a less complex hardware device, referred to herein as a user tag (UT), which operates to identify the user via a wireless cellular communication interface or a non-cellular communication interface such as, for example, a Near Field Communication (NFC) interface, Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Near Field Communication (NFC) or Radio Frequency Identification (RFID), and to connect the user to one or more IODs. In its simplest form, the UT can be a simple, stand-alone electronic device with limited capabilities for transmission (e.g., a toggle switch), but the UT can alternatively be arranged as a conventional smartphone, smartwatch, user device (UD) or user equipment (UE) capable of flexibly providing UT functionality to the user. Alternatively, any type of conventional device that does not require any human interaction (such as, for example, an unmanned autonomous vehicle (UAV) or an Internet of Things (IoT) device) can be capable of operating as a UT.

[0028] Once the UT has access to the appropriate capabilities or functions of one or more IODs and a communication session with the appropriate service providing the function has been established, the user will be able to access at least one of various possible types of services, such as, for example, video on demand (VoD), streaming video service, real-time session video, or an Internet browser application. However, the service provision mechanism is not within the scope of the present invention, but rather focuses on how the IODs are selected and adapted once an ongoing communication session capable of providing the corresponding service has been established between the UT and the server. Thus, as disclosed herein, the scope of the present invention is to maintain an ongoing communication session where the capabilities provided via the IODs can be dynamically adapted whenever the requirements change. It should be understood that in this context, capabilities can be broadly interpreted as such capabilities, such as, for example, the display capabilities allowing the use of the display provided by the IOD, or a certain degree of available capabilities, such as, for example, a certain number or degree of available interfaces or resources (CPU, memory, battery, bandwidth, etc.) capabilities.

[0029] Reference will now be made to Figure 1a and Figure 1b a process for enabling a user or device to have an influence on which IODs or capabilities a communication session will use will be described in more detail. The process is based on the use of a signal called a beacon signal, which is appropriately arranged and transmitted by a UT having an ongoing communication session with an appropriate server, such that an IOD located sufficiently close to the transmitting UT will be able to receive such a signal. The receiving IOD then forwards these received beacon signals to a coordinator capable of coordinating the IODs. Such a coordinator is hereinafter referred to as an IODH, where the content of the combined beacon signals received from the mentioned IODs is used to determine the future configuration of the IODs for the mentioned communication session. Alternatively, the beacon signals are forwarded to the IODH via an EAP authenticator, for example, if EAP signaling is applied to the mentioned communication.

[0030] The beacon signals allow the IODH to track the available IODs and use the information of the beacon signals to estimate or determine the geographical location of the IODs and use this information when determining how the available IODs will be used by the UT. However, a more dynamic mechanism is provided by also allowing the UT to modify the beacon signals when the requirements regarding the capabilities used change and by allowing the IODs and the IODH to identify such modified beacon signals.

[0031] As a prerequisite for the proposed method, a communication session has been initiated between the UT and a server (not shown) capable of providing the requested service. Figure 1aA signaling diagram showing how beacon signals sent by the UT 100 during such an ongoing communication session can be processed by a system including a plurality of IODs 200a, 200b, 200c (which may be referred to as a set of IODs) and an IODH 300 that manages or coordinates the IODs 200a, 200b, 200c.

[0032] It should be understood that the systems presented herein generally also include additional functional entities, such as, for example, the servers mentioned above that provide services to the UT 100, and may also include an authenticator, and the processes described may include additional steps, but only those entities and steps necessary to understand the core of the invention as disclosed herein are incorporated into the figures of this document (including Figure 1a and Figure 1b ).

[0033] In Figure 1a the first step 1:100, the UT 100 sends a beacon signal in a conventional manner (i.e., including data), typically broadcasting the signal repeatedly at some known interval so that the IODH can estimate or determine the positions of the IODs 200a, 200b, 200c. The beacon signal sent is received by the IODs 200a, 200b, 200c located near the UT 100, i.e., the IODs 200a, 200b, 200c are close enough to the UT 100 to be able to successfully receive the beacon signal. In this example, all three IODs 200a, 200b, 200c are able to receive the regular, so far unmodified, beacon signal, which includes at least a session ID and may also include a MAC and freshness parameters such as, for example, a sequence number. All the mentioned IODs 200a, 200b, 200c then forward the received beacon signal to the IODH 300 in subsequent steps 1:200a, 1:200b, and 1:200c, respectively. Once the IODH 300 has received the beacon signal, the IODH 300 will be able to consider the received information accordingly for coordination purposes.

[0034] In another step 1:300, a change in the requirements from the IOD set is triggered at the UT 100, for example, by identifying a proposed need for a particular, unavailable, or different capability so far, or by identifying the occurrence of an event at the UT 100 that requires a change in the current IOD set, but does not necessarily specify any particular capability requirements, and in yet another step 1:400, the UT 100 responds to the changed requirements by modifying the beacon signal according to the relevant trigger, the relevant trigger including changing the content of the beacon signal so that it can indicate more or less detailedly that the current IOD set needs to be reconsidered by the IODH 300, with or without the support from the IODs 200a, 200b, 200c, as will be further elucidated below.

[0035] Additionally, as will also be described in further detail below, the modified beacon signal may also include information on how or how it is intended to be sent by the UT 100, such that this information can also be used later by the IODH 300 for further support in interpreting the conditions and requirements of the UT 100 regarding the IODs 200a, 200b, 200c and in determining how to handle the forwarded beacon information and how to modify the IOD set. Then, in step 1:500, the modified beacon signal is sent, allowing each of the IODs 200a, 200b, 200c that can still successfully receive the modified beacon signal to do so.

[0036] As Figure 1aAs indicated in the example, in one of steps 1:200a to 1:200c, each IOD 200a, IOD 200b, IOD 200c that receives an unmodified beacon signal also receives a modified beacon signal, and each of these IODs 200a, IOD 200b, IOD 200c also forwards the beacon signal to IODH 300 in corresponding steps 1:600a, 1:600b, and 1:600c. Depending on the configuration of the system, forwarding can mean that only information identical to that received by IODs 200a, IOD200b, IOD 200c is forwarded to IODH 300, or it can mean that the forwarded beacon signal is accompanied by additional information added by the respective IODs 200a, IOD 200b, IOD 200c, where such information can include, for example, an indication of the signal strength of the modified beacon signal received by the respective IODs 200a, IOD 200b, IOD 200c, and / or only the portion of the received information necessary for IODH 300 is forwarded to IODH 300. This means that although in steps 1:200a, 11:200b, and 1:200c, IODH 300 only receives information identical to that received by the respective IODs 200a, IOD 200b, IOD 200c, according to one embodiment, the information provided to IODH 300 in steps 1:600a, 1:600b, and 1:600c can be the same, or can be distinguished from the information received by the respective forwarding IODs 200a, IOD 200b, IOD 200c based on additional information added by, information removed by, or a combination of both, the IODs 200a, IOD 200b, IOD 200c. By allowing each IOD 200a, IOD 200b, IOD 200c to adapt the information to be forwarded, each IOD 200a, IOD 200b, IOD 200c will be able to support IODH 300 by providing further useful information, or ensure that certain information not needed by IODH300 will not be forwarded to IODH 300. More specifically, each IOD 200a, IOD 200b, IOD200c can apply filtering to determine whether the received information will be needed by IODH 300. It should be understood that the signal strength may already have been forwarded together with the unmodified beacon signal, for example, to assist IODH 300 in estimating the geographical location of IODs 200a, IOD 200b, IOD 200c. However, according to the present invention, such information can be used by IODH 300 not only for estimating the geographical location of IODs 200a, IOD 200b, IOD 200c, but also for adapting the set of IODs.

[0037] In another step 1:700, the IODH 300 considers the information of the already forwarded information received from all IODs 200a, 200b, 200c (here all three IODs), and based on this information, determines how to adapt the currently active set of IODs to meet the changed requirements indicated by the UT 100.

[0038] Figure 1b Illustrated is how a system according to another embodiment can process a modified beacon signal, where filtering of the modified beacon signal is applied by the IODs 200a, 200b, 200c, i.e., the IODs 200a, 200b, 200c not only forward the modified beacon signal, but also participate in the evaluation process by determining which parts of the modified beacon signal are to be provided to the IODH 300 for consideration and which parts are not to be considered by the IODH 300, and can thus refrain from forwarding the modified beacon signal or parts of the modified beacon signal. Steps 1:100 to 1:500 are the same in both the embodiment and the figure. However, as can be seen in Figure 1b only the IODs 200a and 200c forward all or parts of the modified beacon signal, while as indicated in step 1:601, the IOD 200b refrains from forwarding any signal because even though all three IODs 200a, 200b, 200c are able to successfully receive the modified beacon signal, certain conditions for the IOD 200b to forward the same signal are not met, i.e., the IOD 200b does not consider it to be in the foreground of the modified set of IODs for the ongoing session. Such a decision can be, for example, because the IOD 200b is already busy, serving another communication session, or because the signal strength of the modified beacon signal (although sufficient to be able to receive the modified beacon signal) is below the minimum threshold set for the IOD 200b.

[0039] In accordance with Figure 1a and Figure 1b The process described in the signaling diagram is generally repeated as long as the communication session is ongoing, and different processes associated with different communication sessions and different associated sets of IODs are generally also managed in parallel by the IODH 300. Even though Figure 1a and Figure 1bBoth indicate that the IODs 200a, 200b, 200c are directly forwarding unmodified and modified beacon signals to the IODH 300, which signals can also alternatively (as already mentioned) be sent via an authenticator (not shown), such as for example an EAP authenticator, such that the EAP authenticator can thereby ensure that only authenticated beacon signals are received and processed by the IODH 300. However, if the system is configured such that the beacon signals are not verified by the EPA authenticator, they can alternatively be verified by the IODH 300 instead. If for example the beacon signal is formatted as an EPA identity response message, the IODs 200a, 200b, 200c can forward such a message in its simplest form to the EAP authenticator, while according to another embodiment, the IODs 200a, 200b, 200c are alternatively configured to first check the beacon signal, identify the beacon signal as a regular identity response, in which case the beacon signal is forwarded to the EAP authenticator, or identify the beacon signal as a beacon identity response, in which case it is alternatively forwarded to the IODH 300 for processing by the IODH 300.

[0040] As already mentioned, the UT can be any from a minimalist restricted device to a more or less manually or automatically processed complex communication device, the minimalist restricted device including more or less only communication capabilities, and some triggering component, which can be activated manually or automatically without any human interaction such that the modification of the beacon signal can be triggered. The UT can include some UI functionality for allowing a human or automated user to trigger the modified beacon, but as described above, a UT lacking UI functionality can also be able to perform the mentioned triggering, for example, by triggering based on the geographical location of the UT, the time of day, the day of the week or any other parameter that can be recognized by the UT.

[0041] Now reference will be made to Figure 2 A method that can be executed at the UT will now be described in more detail, as described herein, the UT being capable of adapting the connectivity with available IODs during an ongoing session by modifying beacon signals. As a prerequisite, it is considered that the UT participates in an ongoing session with a service via a set of one or more IODs, and the method is being executed until the ongoing session is terminated, i.e., regular or modified beacon signals as described herein will be sent at some interval between transmissions as long as the session is ongoing at the UT. For battery saving purposes, the repetition scheme applied to the beacon signals can be adaptive such that for example the beacon signals are sent less frequently at night than during the day.

[0042] As already mentioned above, as indicated by the first step 200, the UT typically sends beacon signals on a continuous basis for an ongoing session, i.e., as shown by another step 210, as long as checking whether a modification to the beacon signal is needed results in the modification not being needed. However, once the UT identifies such a trigger, the current beacon signal is modified according to the relevant standard, as indicated by step 220.

[0043] The modification of the beacon signal can be based on one or more criteria. According to one embodiment, user interaction is detected at the UT, where the user interaction indicates a request for adaptation of the IOD set, or at least an assessment of the possibility of adaptation. The trigger for modifying the beacon signal can be initiated manually by the user of the UT, e.g., by activating a physical or digital button; automatically, by relevant logic activated at or in combination with the UT, e.g., based on the occurrence of a certain event, such as the UT entering a specific geographical area that can be recognized by the UT, or by a combination of manual and automatic decisions. Here, the user is interpreted as a human user or an autonomous device or machine capable of handling the relevant functions of the UT (including triggering the modification of the beacon signal).

[0044] According to one embodiment, the trigger responds to an immediate need for a change to the beacon signal, while according to another embodiment, the fact that a modification is needed can be a decision manually triggered by the user via a first trigger, identifying, for example, an additional ability that is soon needed or to be evaluated, and the actual time instance of the modification of the beacon signal can be triggered separately by a second trigger after the first trigger, e.g., due to the same or another trigger criterion applied to the first trigger. Such a subsequent trigger can be executed automatically, for example, after the initial manual decision has been made, such that the modified beacon signal is sent in a certain time slot, or the modified beacon signal is sent once it has been determined that a second event has also occurred. According to yet another embodiment, the actual time instance for sending the modified beacon signal is also determined based on a manually executed trigger.

[0045] Depending on whether the decision on how to adapt the IOD set is taken entirely by the IODH in response to receiving the sent, modified beacon, i.e., the UT only triggers when to modify the IOD set without affecting how the IOD set will be adapted, or whether the UT also has an impact on the mentioned adaptation, the modified beacon signal can be assembled at the UT such that it includes one of different possible combinations of information that is inserted into different new data fields and thus adjusted, which will be described in further detail below.

[0046] According to another embodiment, the triggering can be fully automatic, such that for example when one or more sensors indicate that a specific event has occurred, such as when the UT has entered a specific environment. Such an automated process can also be based on one or more profiles, where each profile is associated with one or more events, tasks, environments, or use case scenarios, and may also be associated with event-specific capability requirements. Thus, one or more sensors incorporated on or accessible to the UT can be used to indicate that a certain event or use case has occurred, and thus activate a certain predefined profile, which triggers a specific modification to the beacon signal and inserts a certain set of information into the beacon signal according to the selected profile, the specific modification and insertion corresponding to an elevation of a certain requirement, such as information regarding a certain set of required capabilities.

[0047] As an example, a profile can refer to a specific type of video conference, including required capabilities, screen, touchpad, camera, speakers, and microphone, while another profile referred to as document editing can include capability requirements limited to a screen and a mouse as well as a keyboard, touchpad, notepad, or pointing device. Different environments can be specified as, for example, work, home, and public transportation, each environment being default associated with different capability requirements. Profiles can also be specified according to, for example, the time of day and / or the workday, thereby profiling certain capabilities, differentiating the default profiles for normal working hours and normal idle hours as well as for workdays and weekends. The user of the UT can also be able to activate a certain profile associated with a certain task, such as a video call or document editing, by scanning a specific, associated NFC tag or QR code, etc. on demand. Alternatively, such profiles can be accessed and activated based on voice control.

[0048] According to another embodiment, the modified requirement is based on determining that the UT is located at a certain geographical location, requiring an adaptation of at least one set of IODs, such that for example a user close to home triggers the UT to send a modified beacon signal requesting the capabilities required to assist the user to enter home in a safe manner. According to yet another embodiment, a time aspect (such as for example the occurrence of a certain time instance, a certain day of the week, or entering a certain time interval) can determine that a change in the requirement needs to be signaled by the modified beacon signal.

[0049] Once the beacon signal has been modified, the modified beacon signal will replace the regular beacon signal so far as the signal to be transmitted by the UT, as indicated in step 230. Transmission of the modified beacon signal will typically continue for a specific number N of transmissions, after which the regular beacon is transmitted again. Alternatively, in the event that the first N transmissions are determined to have failed, e.g., because the user did not obtain access to the IOD as desired or expected for a particular session, the transmission of the modified beacon can be repeated for an additional N transmissions, e.g., by re-pressing the activation button on the UT, to make a new attempt to update the IOD.

[0050] According to one embodiment, the beacon signal prior to the modified beacon signal can include information that may be relevant when the IOD and IODH process the modified beacon signal. Such a beacon signal can include, for example, one or more of an indication of the power class applied by the UT when transmitting the previous beacon signal and an indication of the maximum allowable transmission power level applied by the UT when transmitting the previous beacon signal, such that the IODH can use such information, e.g., for estimating the geographical location of the corresponding IOD.

[0051] According to one embodiment, the UT can transmit a modified beacon signal with a flag set to "requested modification" by applying an initial transmission power, followed by N subsequent modified beacon signals that are transmitted with a gradually decreasing transmission power, i.e., at each transmission step, the transmission power is reduced by an amount that can typically be in the range of 1 to 10 dB. In this case, only the IODs close to the UT will receive and forward the information in the latest of the N modified beacon signals. Thereby, the IODH can be able to estimate which IOD is located closest to the UT based on the modified beacon signals received in the N forwarded beacon signals.

[0052] Alternatively, the modified beacon signal can include, for example, only the transmission configuration data to be sent in the initial beacon. Thereby, one or more of the power class, maximum and / or minimum transmission power applied by the UT can be provided to the IOD and IODH, allowing the IOD to use such information to determine which received beacon signals to forward to the IODH, or allowing the IODH to use such information when analyzing the forwarded beacon signals and determining how to adapt the IOD set.

[0053] According to another embodiment, the first transmission at a low transmission level can be followed by N repetitions where the transmission power gradually increases, such that the IODH can, for example, determine based on a freshness parameter that the previous transmission has been lost and can consider only the signals received first from the IODs, e.g., received from the most preferred IODs.

[0054] According to yet another embodiment, in a first transmission, the UT may also include radio transmission details that indicate to the IODH that for a certain session ID, N transmissions with a constant or gradually increasing or decreasing transmission power will follow the first transmission. Thereby, the IODH will be able to also use this information when determining the correlation of the received information with the modified beacon signal. Alternatively, the radio transmission details to be applied are applied according to preconfigured details known to all entities involved in processing the modified beacon signal. According to yet another embodiment, the occurrence of a certain event is decisive for the modification of the beacon signal.

[0055] As already mentioned, the content of the modified beacon signal may vary depending on what data the adaptation of the IOD set is to be based on. In its simplest form, the modified beacon signal includes a session ID and an indication that can indicate a need for modification, where the added content may include an added data field of the beacon signal, configured as follows.

[0056] Session ID; Modification indicator / flag (1)

[0057] The session ID identifies the relevant ongoing communication session associated with the modified beacon signal. Based on this parameter, as long as the communication session is ongoing (i.e., has not been terminated), the IOD set available to the user of a certain UT can be adaptively modified, because the IODH will be able to distinguish between modified beacon signals associated with different communication sessions. In addition, some capabilities, such as for example a mouse, may not be suitable for sharing by different ongoing communication sessions, while others such as a display may be suitable for sharing. The modification indicator can be provided in its simplest form, for example in the form of a logical flag, which indicates that the signal is a modified beacon signal if the logical flag is set to "true" or "1", while if the logical flag is set to "false" or "0", the signal will be interpreted as a normal or unmodified beacon signal. If only the session ID and the modification indicator are used in the modified beacon, the IODH will adapt the IOD set without any impact on the decisions from the UT.

[0058] As will be illustrated below, the above indication may alternatively be replaced or accompanied by other details about the actual required adaptation of the IOD set, which enables the receiving entity to distinguish the modified signal from the unmodified signal.

[0059] Even though the simplest modified beacon signal for performing the proposed method only includes two added fields as proposed above, a sufficiently secure arrangement will generally also require adding additional security-related fields, thus also adding one or both of the following:

[0060] Freshness parameter, Encryption protection (2)

[0061] The freshness parameter is a parameter updated at the UT for each transmission, allowing the receiving entity to determine whether the received beacon signal is a new signal or a replayed signal. For this purpose, a sequence number (SQN) updated for each beacon transmission can be applied. Such a sequence number can, for example, apply wrapping, i.e., once the bit space is exhausted, the sequence starts again from 0.

[0062] Encryption protection will reduce the risk of spoofing beacon signals. By applying a certain type of initiator encryption proof, such as a keyed hash (message authentication code (MAC)), to at least a part of the modified beacon or the modified beacon signal, such as at least the session ID, modification indicator / flag, and SQN, these most sensitive parts of the forwarded information can be protected. Alternatively, even though encryption protection is generally always preferred, encryption protection can alternatively be applied only in cases where the modification indicator / flag indicates that a modification is required.

[0063] In the case where the Extensible Authentication Protocol (EAP) is applied for authentication, the MAC can be calculated using a key derived from the EAP authentication, such as, for example, a pairwise master key (PMK) or a key derived from the PMK. In this case, an independent authenticator or an authenticator forming part of the IODH uses the obtained PKM (possibly together with the session ID) to derive an IOD-specific session key. The UT acting as the EAP client here also derives the PMK in this scenario. Thereby, a key that can be used directly or indirectly to protect the beacon is provided.

[0064] According to another embodiment, the beacon signal can also include information specifically regarding the capability requirements, i.e., specific information about which capabilities will be required to maintain an ongoing session, even if its conditions may have changed during the session. Changes in the capability requirements can be applied such that the UT signals, for example, a requirement for the removal of a capability allocated to an ongoing communication session that is no longer needed for the ongoing communication session, e.g., due to the completion of a certain task. Alternatively, the change can signal a requirement for the addition of a capability to an ongoing communication session that is needed for the ongoing communication session, e.g., due to entering a meeting room, increasing the need for meeting facilities. The replacement of one type of capability with another more suitable for the ongoing communication session can be illustrated, for example, by requesting the replacement of a small screen with a larger screen when entering home or work or when a certain event triggering the need for a larger screen occurs at the UT.

[0065] According to one embodiment, a modified beacon signal including a session ID and a capabilities field (where the latter replaces the modified beacon signal flag) can constitute a relatively simple modified beacon signal, while according to another embodiment, the mentioned fields can supplement the modified beacon signal flag. However, as described above, in a typical scenario, the modified beacon signal will also include a freshness parameter and some type of security protection for at least the most critical part of the signal in order to provide at least a minimum level of security protection when signaling the need for an update of the IOD set.

[0066] The capabilities field added to the modified beacon signal can include an indication of one or more capabilities determined to be required by a specified ongoing communication session and can include, for example, an indication of one or more of the following: screen, display, speaker, camera, microphone, mouse, keyboard, touchpad, inertial measurement unit (IMU), light source, sensor, and actuator. Alternatively, some or all of the indicated capabilities can be even more detailed, in cases where the broad terms are not sufficient to describe the IODH, such that the camera capability can be specified as, for example, a 360 camera or a thermal camera, the display can be specified as, for example, a holographic display or an electroactive polymer (EAP) display, the sensor can be specified as, for example, a temperature sensor or an inertial measurement unit (IMU), the light source can be specified as, for example, an LED light or infrared light, or the actuator can be specified as, for example, a touch button or a robotic arm. The capabilities field can be configured, for example, as a field including multiple bytes, where each bit indicates a particular type of required capabilities category.

[0067] For example, the least significant bit can indicate the mouse, the second least significant bit can indicate the screen, and the third least significant bit can indicate the microphone. Alternatively, multiple bytes can represent each category, allowing for the indication of one or more of the same type of capabilities, such as two screens, or different types of capabilities within a category, such as different sensor types. Even in a scenario with a very low-complexity UT, such as a UT having only one actuation button, a system for identifying various types of capabilities can be applied if, for example, the UT is configured such that pressing the button a certain number of times is interpreted as symbolizing a request for different corresponding types of capabilities. Thus, a rather simple UT including only one button can also provide the user with several optional options and a wide range of flexibility. According to another embodiment, another dedicated button used as a "profile" button is configured to select one of the previously mentioned profiles, such that certain sets of capabilities requirements can be selected in that way, thus simplifying the user's assembly of a suitable request, requiring a minimum of input from the user.

[0068] Depending on the type of trigger, user actuation of one or more actuators, the logic of the UT, or a combination of both can initiate a consideration according to any of the embodiments suggested above, where different considerations can be weighted against each other and / or prioritized according to certain static rules or according to more dynamic rules, where one or more of, for example, geographical location, time of day, type of session or content of the session, occurrence of a certain event, or estimated distribution of IOD can be considered individually or in combination.

[0069] The adapted beacon signal can be configured as a plain bit string carrying information according to any of the embodiments above. Alternatively, the information presented above can be carried as an identifier in an EAP identity response message, with the EAP message acting as a beacon. In this case, the modified beacon signal can also include a beacon ID, which is a parameter that specifically differentiates the beacon signal from the EAP identity response message. With the latter scheme, when there is no active communication session, the UT can broadcast a beacon in the form of an EAP identity response message, where the identifier carried is the identifier of the UT and points to the associated EAP server. Once the UT has established a communication session, the identifier carried in the EAP message used as a beacon signal can subsequently be replaced with the beacon format, as previously discussed. For the UT, this will simplify things because the beacon signal will always be an EAP message, which can be used for both initial authentication and management of an existing communication session. The EAP message can be automatically routed by the receiving IOD to an EAP authenticator in the domain, or the IOD can identify the beacon signal as a communication session-specific beacon and thus forward it to the IODH. If all EAP beacon signals are sent to the EAP authenticator, a distinction must be made between the initial authentication and the session communication beacon signal. This can be done using a dedicated beacon ID or any other differentiating format / content of the identifier carried (by the IOD or the EAP authenticator).

[0070] Reference will now be made to Figure 3 a method capable of receiving and processing a modified beacon signal received from a UT at an IOD will be described in more detail. As a prerequisite, it is considered that the UT participates in an ongoing session with a service via a set of one or more IODs, including the IOD on which the method is executed, as described below. Additionally, the methods described herein at the IOD are generally executed in parallel at multiple IODs.

[0071] The IOD is located close enough to the UT to successfully receive the beacon signal, as indicated by the first step 300. As long as the received beacon signal is not identified as a modified beacon signal, as indicated by the "No" branch of step 310, the received beacon signal is simply directly forwarded to the IODH, or forwarded to the IODH via the EAP authenticator, as indicated by step 320a, and then waits for the reception of another beacon signal. In the case where the beacon signal is an EAP identity response, the beacon signal is typically forwarded to the EAP authenticator before being forwarded to the IODH by the EAP authenticator.

[0072] However, if it is determined at the IOD based on the content of the received beacon signal that the received beacon signal has been modified, as indicated by the "Yes" branch of step 310, the IOD may also forward only the modified beacon signal and leave all evaluations of the adaptation of the IOD set to the receiving IODH. Alternatively, the IOD may act on the adaptation process according to one or more options. As indicated by the optional step 320, additional content, such as, for example, the received signal strength, may be included in the modified beacon signal, and / or, in the case where a filtering function is applied, as indicated by the optional step 330, the IOD may apply relevant filtering criteria to determine whether to suppress the forwarding of the modified beacon signal, as indicated by the "Yes" branch in step 340, or whether to forward according to step 350, as indicated after the "No" branch in step 340. If necessary, the filtering may also determine which content of the modified beacon signal to forward and which data to discard, as well as suppress the forwarding. An advantage of filtering which modified beacon signals to forward is that the receiving IODH will have to evaluate less but more relevant information and thus have a lighter load. On the other hand, the advantage of forwarding all or most of the content of the modified beacon signal received by at least one IOD is that the IODH will be provided with a more complete picture of the available and capable IODs and possible combinations of IODs and thus be able to make a more optimized selection and combination of IODs. The latter scenario may be advantageous, for example, when the IODH is going to determine how to share shareable resources (such as a screen) between different communication sessions in an efficient manner, and may also be advantageous when more complex selection criteria are applied by the IODH.

[0073] In the case where filtering is to be applied, according to one embodiment, such filtering may be based on the received signal strength of the modified beacon signal as a filtering criterion, regardless of whether such filtering is for determining the forwarding or non-forwarding of the IOD. Thus, the IOD may selectively forward all or part of the modified beacon signal only when it is found that the received signal strength exceeds a certain signal strength threshold.

[0074] According to another embodiment, if the modified beacon signal includes at least one capability field and the IOD fails to provide any of the one or more required capabilities indicated in such a field, forwarding of the modified beacon signal may be inhibited. In such a scenario, the IOD will be clearly useless for the ongoing session and thus there are no relevant options for the IODH during the selection of a suitable set of IODs.

[0075] According to yet another embodiment, the IOD may determine that it is unable to function for the communication session associated with the received modified beacon, for example due to serving another ongoing communication session.

[0076] According to yet another embodiment, IOD-specific capacity-related information (such as for example its battery capacity, interface capacity, processing power or available storage capacity) may be used as a filtering criterion to ensure that the IODH only considers IODs having a sufficient amount of a particular capacity. As an alternative to one or more of the above filtering criteria, one or more of the corresponding parameters may alternatively be inserted into the modified beacon before being forwarded, such that alternatively the IODH may consider, for example, the available storage capacity of each available IOD when determining a suitable set of IODs.

[0077] As described above, the IOD may forward the modified signal to an authenticator, such as for example an EAP authenticator, instead of forwarding the modified beacon signal directly to the IODH. According to yet another embodiment, the IODH may include such an EAP authenticator.

[0078] As already hinted at above, the IODH makes the final decision on how to adapt the set of IODs in response to having received at least one modified beacon signal initiated by the UT. Even though each IOD may contribute to such a decision, it will be only the IODH which will have the overall or final picture of the current IOD situation, i.e., the currently used IODs and potential IODs, such that after incorporating the content from the received modified beacon signal, it will be able to evaluate all the information provided in the modified beacon signal and select a suitable set of IODs including one IOD or a combination of IODs for the corresponding ongoing communication session.

[0079] Reference will now be made to Figure 4 A method executable at the IODH will be described in more detail, which is able to decide on a modification of the set of IODs as part of its management function, based on information about modified beacon signals received from IODs currently participating in an ongoing communication session. As a prerequisite, at least one IOD, which makes its capabilities available to the UT, is forwarding the received modified beacon signal information, with or without additional IOD-specific information added to the modified beacon signal for evaluation and processing at the IODH.

[0080] The IODH is receiving information about beacon signals from the IOD, as indicated in step 400. Typically, step 400 also includes determining the freshness of the received signal, i.e., differentiating a first modified beacon signal from a repeated beacon signal, where Figure 4 only describes how to process the first received beacon signal, and the repeated beacon signals arriving at the IODH are discarded by the IODH. By recording the repeated beacon signals, the IODH can use such information as a basis for determining that an attack attempt is in progress. If the proposed features for determining freshness are applied, step 400 may also, unless completed at the authenticator.

[0081] If the received beacon signal information does not indicate the reception of a modified beacon signal, as indicated by the "No" branch of step 410, the IODH executes or processes the information obtained by the IODH in a conventional manner, which is outside the scope of this document, as shown in step 420a, and then the IODH waits for a new beacon signal. However, if the IODH interprets the information as indicating a modified beacon signal, as indicated by the "Yes" branch of step 410, then alternatively the received information is processed for the purpose of first determining whether the current IOD set associated with the mentioned communication session is required, or can be modified based on the information obtained, as indicated in step 420b.

[0082] The determination of whether a modification of the IOD set is needed or possible is achieved by comparing the available information about the current IOD set (such as, for example, the capabilities available from the mentioned IOD set) with the capabilities required according to the modified beacon signal information. If the requirements are met, no modification will be needed and the described process will terminate, to be re-initiated again once the IODH receives new modified beacon signal information, as indicated by the "No" branch of step 420b. The latter case can occur, for example, when the requirements from the UT indicate a need for a change in the IOD set, but where the IODH determines that the continued execution of the ongoing communication session will be possible and that the change in the IOD set will not improve the overall situation between the ongoing sessions. Alternatively, in the "best possible" scenario, for example when no additional or alternative IODs are available, the current IOD set can be maintained.

[0083] However, if the IODH determines that the current IOD set will not be able to serve according to known requirements and there are additional or alternative IODs available, it determines how the IOD set should be modified, as indicated in step 430. Such determination should have the goal of selecting an optimal IOD set based on the applied criteria and can be performed based only on the content available to the IODH of the received modified beacon signal, or based on the mentioned information, in combination with additional IOD-specific information included by the IOD with the forwarded modified beacon signal (such as, for example, the received signal strength), thus constituting the modified beacon signal information. Additionally, the IODH can generally access and consider one or both of certain pre-stored information and logic on the IODs, i.e., the rules on how to combine, evaluate, and prioritize the available information, which may include rules on how to weight various parameters relative to each other.

[0084] More specifically, the IODH can select IODs / capabilities by determining to remove one or more IODs that can only provide capabilities that will no longer be required, or it can remove an IOD that has only one capability and replace it with another IOD that includes multiple required capabilities. If a currently unavailable capability is needed, one or more suitable IODs can be added or replaced, i.e., during the determination phase of step 430, the addition, removal, and replacement of IODs may be relevant. If multiple suitable IODs are available, the IOD estimated to be closest to the UT can be selected if such information is available to the IODH. However, other considerations can also be taken into account, such as, for example, the active constellation of shared resources between different ongoing communication sessions or the combination of capabilities at different IODs. According to one embodiment, the IODH can also or alternatively consider user preferences, e.g., such that a certain user has specified that, in the case where a particular type of IOD is among the available options, if the received signal strength is higher than a certain threshold, then that IOD is always used or switched to, or used or switched to under certain conditions.

[0085] Once the determination of the modification has been made, in another step 440, the relevant IODs are instructed by the IODH of the determination, and thereafter, the method is repeated when the next modified beacon signal is received.

[0086] Although Figure 4A flowchart showing the reception of only one beacon signal is presented. However, it should be understood that in a typical scenario involving more than one IOD, all these IODs handle the same communication session and have received the associated modified beacon signal. The determination in step 420b and step 430 will be based on the combined information received from all relevant IODs. More specifically, if the requirements of the current IOD set are also met according to the requirements of the received modified beacon signal, the current IOD set is maintained, and if this is not the case, it will be modified by considering the information from all relevant IODs in step 430. Thus, according to step 440, all IODs involved in the determined modification are instructed in separate instructions.

[0087] The determination of the modification of the IOD set can be based on considering available IODs, where different types of IODs (such as screens, speakers, etc.) may have been grouped into different corresponding groups, for example, depending on the combination of capabilities. By considering the received transmission power of the IODs and the available groups, and how the received transmission power varies among the different received beacon signals or portions of the N forwarded signals, the IODH can determine an optimized IOD set.

[0088] The IODH will determine how to configure the current IOD set for the corresponding ongoing communication session based on the information accessible in the received information regarding one or more modified beacon signals. The IODH will use the obtained beacon identifier to identify the received signal as a beacon signal, unless the IODH is configured to identify this signal accordingly based on other content of the received information (such as the presence of information regarding the required capabilities). The IODH can also identify the session ID from the received information so that it can distinguish and merge the information associated with a specific communication session. By further evaluating the freshness parameter of the received modified beacon signal, the IODH will be able to distinguish the first modified beacon signal from subsequent beacon signals.

[0089] If at least a portion of the received information is also protected by the initiator's encryption proof, the IODH will verify the integrity of these portions of the information accordingly. As already mentioned, according to one embodiment, the IOD can also include an indication of the signal strength of the received modified beacon signal into the information forwarded to the IODH. Thus, the IODH will be able to use such signal strength information to estimate the distance between the UT and the corresponding IOD, so that based on these estimates, those IODs estimated to be closest to the UT location can be prioritized when determining how to best modify the IOD set. If the capability requirements are included in the received information, certain possible combinations of IODs that meet these capability requirements and other available parameters can be considered.

[0090] In addition to the above information, the IODH may also access additional information that is considered when determining how to modify the IOD set. If the IODH can also access information about the amount of available capabilities in each relevant IOD, such information can be considered during the determination process mentioned above, such that, for example, in the case where there is at least one IOD with two or more of the requested capabilities available, all IODs with only one of the requested capabilities available may not be considered potential IODs in the modified IOD set. If, for example, one or more of the battery capacity, amount of processing power, amount of interface capacity, or amount of available storage capacity at each relevant IOD is also accessible by the IODH, corresponding considerations can be done by the IODH.

[0091] To be able to perform the above method, referring to Figure 2 , the UT needs to be adjusted accordingly. Therefore, reference will be made to Figure 5 to further describe in detail a UT according to one embodiment that is configured to perform the method as disclosed herein. Figure 5 The UT 100 of Figure 3 includes a processor circuitry 500 and a memory 510 including executable instructions that are configured to, when executed by the UT 100, cause the method of the UT 100 of Figure 3 to be performed. The memory 510 can be any combination of random access memory (RAM) and / or read-only memory (ROM). The memory 510 generally also includes a persistent storage device, which can be, for example, any single or combination of magnetic memory, optical memory, solid-state memory, or even remotely mounted memory. The processing circuitry 500 can include, for example, one or more central processing units (CPUs), a multiprocessor, or a digital signal processor (DSP).

[0092] Computer-readable instructions configured to provide the functionality described herein can be provided as a computer program 550 configured in the form of a computer program product 560, where the computer program product 560 can be configured to be, for example, an optical disc such as a compact disc (CD), a digital versatile disc (DVD), or a Blu-ray disc.

[0093] More specifically, the UT 100 is capable of adapting the connectivity of the UT 100 provided by the service to the UT 100 via a set of at least one of IOD 200a, IOD 200b, IOD 200c during an ongoing communication session, wherein the UT 100 includes processing circuitry 500 configured to cause the UT 100 to transmit a beacon signal (which may be referred to herein as a regular beacon signal or a beacon signal prior to a modified beacon signal) via communication circuitry 520 during the ongoing communication session, wherein the beacon signal is detectable by at least one of IOD 200a, IOD 200b, IOD 200c when the UT 100 is located near the at least one of IOD 200a, IOD 200b, IOD 200c. When it is determined that adaptation of the set of at least one of IOD 200a, IOD 200b, IOD 200c is needed, the UT 100 is configured to modify the previous beacon signal, wherein the modification includes: including an indication in the beacon signal that indicates a request for adaptation of the set of at least one of IOD 200a, IOD 200b, IOD 200c; and transmitting the modified beacon signal such that one or more of IOD 200a, IOD 200b, IOD 200c located near the UT 100 can participate in the adaptation of the set of at least one of IOD 200a, IOD 200b, IOD 200c.

[0094] Generally, the UT 100 is further configured to transmit a previous beacon signal including a transmission configuration, the transmission configuration including one or more of an indication of a power class applied by the UT 100 when transmitting the previous beacon signal and an indication of a maximum allowable transmission power level applied by the UT 100 when transmitting the previous beacon signal, such that when received by the IODH 300, such information can be used, for example, to estimate the distance between the UT 100 and the IOD 200a, IOD 200b, IOD 200c.

[0095] When the beacon signal is to be modified, the UT 100 is configured to include the beacon signal with specific data into a corresponding dedicated data field, wherein such information will at least include: a session identifier identifying the ongoing communication session, such that the IODH 300 can separately process the beacon signal associated with the specific communication session; and a modification indicator indicating whether adaptation of the set of at least one of IOD 200a, IOD 200b, IOD 200c is requested, i.e., such that the IODH 300 can determine whether the beacon signal is requesting adaptation of the IOD set.

[0096] As already mentioned, the modified beacon signal may include one or more additional parameters provided in other dedicated data fields, depending on what data is considered required by the IODH 300 to be able to determine how best to adapt the current IOD set. More specifically, the UT 100 may be configured to include a beacon identifier indicating that the signal is a beacon signal and will thus be processed according to the mechanisms described in any of the embodiments disclosed herein. The freshness parameter will enable the IODH 300 to distinguish a sent beacon signal from a previously sent beacon signal. The encryption proof of the initiator will enhance security by providing encryption protection for at least a portion of the beacon signal, while an indicator of the capabilities requirements of an ongoing session will provide more specific requirements for the specific capabilities required by the UT 100.

[0097] If the UT 100 is configured to include specific capabilities requirements, such requirements may be specified in the modified beacon signal for one or more of a screen, a display, a speaker, a camera, a microphone, a mouse, a keyboard, a touchpad, a notepad, a pointing device, an inertial measurement unit (IMU), a light source, a sensor, and an actuator.

[0098] The triggering to modify the beacon signal based on the requirements for the modification of the IOD set may be caused or based on several different criteria, either individually or in combination. According to one embodiment, the UT 100 may be configured to detect that a user interaction indicating a request for adaptation of the set of at least one of IOD200a, IOD 200b, IOD 200c has been performed at the UI 530 of the UT 100, such as an optional UI 530 which may be, for example, a button or a touch-sensitive display, or any of the sensors 540 (such as, for example, an inertial measurement unit (IMU)).

[0099] According to another embodiment, the UT 100 may be configured to detect that the UT 100 has entered and is now located at a certain geographical location where adaptation of the set of at least one of IOD 200a, IOD 200b, IOD 200c is required. Alternatively, the UT 100 may detect that a certain time instance has arrived that raises the need for adaptation of the set of at least one of IOD 200a, IOD 200b, IOD 200c, or that a certain time interval has started or expired. According to yet another embodiment, the UT 100 may alternatively be configured to detect that a certain event detectable by one or more sensors (here represented by the optional sensors 540 of the UT 100 or processing logic (not shown)) has occurred.

[0100] The UT 100 can also be configured to repeat the transmission of the modified beacon a specific number of times N, such as 5 times. More specifically, according to one embodiment, the UT 100 can be configured to: after initially transmitting the initial, modified beacon signal using the nominal transmission power, for each of the N repetitions, reduce or increase the transmission power by a specific predetermined amount.

[0101] According to another embodiment, the UT 100 can be configured to include an initial modified beacon signal and a transmission plan associated with N modified beacon signals for subsequent repetitions, thereby notifying the IODH 300 of upcoming repeated transmissions.

[0102] In a situation where the UT 100 is configured to use a modification indicator in the modified beacon signal and repeat the transmission of the modified beacon signal N times, the UT 100 can be further configured to set the modification indicator only during the initial modified beacon, before the N modified beacon signals, thereby allowing the IODH 300 to easily distinguish the first modified beacon signal from the repeated beacon signals.

[0103] According to another embodiment, the UT 100′ including multiple functional units or modules can be configured according to Figure 6 wherein the transmitting unit or communication unit 600 is configured to: during an ongoing communication session, transmit a previous beacon signal that is detectable by at least one of the IODs 200a, 200b, 200c when the UT100′ is located near at least one of the IODs 200a, 200b, 200c, corresponding to Figure 2 step 200; the modification unit 610 is configured to: when determining the need for adaptation of a set of at least one of the IODs 200a, 200b, 200c, modify the previous beacon signal, where the modification includes adding an indication to the beacon signal that includes a request for adaptation of the set of at least one of the IODs 200a, 200b, 200c, corresponding to Figure 2 step 220, and wherein the transmitting unit 600 is further configured to: transmit the modified beacon signal such that one or more of the IODs 200a, 200b, 200c located near the UT 100′ can participate in the adaptation of the set of at least one IOD, corresponding to Figure 2 step 230. The UT 100′ can also be configured to recognize user interactions input to the UI 100′ via the user interface (UI) 620. In addition, the UT 100′ can be configured to capture one or more parameters via one or more sensors (represented here by the optional sensor 630).

[0104] Moreover, the IODs need to be adapted so that they can execute the method according to Figure 3 . Accordingly, reference will now be made to Figure 7 for a further detailed description of the IOD 200 configured to execute the methods as disclosed herein. With respect to the IOD 200, applying the mechanisms disclosed herein, the IOD 200 can be any type of device including communication capabilities and at least one capability that can be utilized by a user of the UT 100 once a communication session has been initiated between the UT 100 and a service. Thus, a certain communication session can utilize a collection of IODs 200a, 200b, 200c, where each IOD 200a, 200b, 200c in such a collection can provide different or similar capabilities that together meet the requirements of the corresponding communication session, or a single IOD 200 can provide all of the capabilities required for the communication session. The IOD 200 can thus be, for example, a computer, laptop, or tablet PC that includes multiple capabilities, or, for example, a display, mouse, keyboard, notepad, digital camera, or pointing device that provides one or more types of capabilities to a communication session.

[0105] The IOD 200 includes a processor circuitry 700 and a memory 710, the memory 710 including executable instructions configured to enable the IOD 200 to execute the method according to Figure 3 . The memory 710 can be any combination of random access memory (RAM) and / or read only memory (ROM). The memory 710 generally also includes a persistent storage device, which can be, for example, any single or combination of magnetic memory, optical memory, solid state memory, or even remotely mounted memory. The processing circuitry 700 can include, for example, one or more central processing units (CPUs), multiprocessors, or digital signal processors (DSPs).

[0106] Computer-readable instructions configured to provide the functionality as described herein can be provided as a computer program 750 configured in the form of a computer program product 760, where the computer program product 760 can be, for example, an optical disc such as a compact disc (CD), digital versatile disc (DVD), or Blu-ray disc.

[0107] More specifically, the IOD 200 is capable of operating in adapting connectivity during an ongoing communication session provided by a service to the UT 100 via the IOD 200. The IOD 200 includes processing circuitry configured to cause the IOD 200 to receive, via the communication unit 720, a beacon signal associated with the ongoing communication session and transmitted by the UT 100 to the IOD 200. After that, the IOD 200 is configured to determine, at least in part based on the content of the received beacon signal, whether the received beacon signal is a modified beacon signal, whether the received beacon signal is to be forwarded to the IODH 300 or the IOD 200 is to refrain from forwarding the modified beacon signal. When determining how to adapt the set of IODs, the considerations mentioned allow the IOD 200 to selectively forward only the modified beacon signal or the portion of the modified beacon signal that is considered relevant to the IODH 300. Finally, the IOD 200 is configured to forward at least a portion of the content of the received modified beacon signal to the IODH 300, thereby enabling the IODH 300 to determine how the IOD 200 will act during the adaptation of the set of at least one IOD when it is determined that the received beacon signal is a modified beacon signal and at least a portion of the content will be forwarded.

[0108] According to one embodiment, the IOD 200 is further configured to obtain an indication of the signal strength of the beacon signal when received by the IOD 200.

[0109] According to another embodiment, the IOD 200 is configured to forward the received beacon signal only if a filtering criterion for forwarding the received beacon signal is satisfied. If filtering is applied, the IOD 200 may be configured to filter based on one or more filtering criteria, which may be based on one or more of the following: the signal strength of the received beacon signal, such that, for example, only modified beacon signals received with a signal strength exceeding a certain threshold are forwarded; the battery capacity of the IOD 200, such that the modified beacon signal is only forwarded from the IOD 200 if the battery capacity of the IOD 200 exceeds a certain threshold; the capabilities available at the IOD 200, such that the modified beacon signal is only forwarded if one or more specific capabilities are available for use by a particular communication session at the IOD 200; the processing power available at the IOD 200, such that the modified beacon signal is only forwarded if the processing power available at the IOD 200 exceeds a certain threshold; and the storage capacity available at the IOD 200, such that the modified beacon signal is only forwarded if the storage capacity of the IOD 200 exceeds a certain threshold. Any proposed filtering criterion may be based on factual values or estimated values.

[0110] Once the IOD 200 has received the modified beacon signal and has determined that at least some of the content is to be forwarded to the IODH 300, the IOD 200 can also be configured to include one or more parameters into the received modified beacon signal: the signal strength of the received beacon signal; the battery capacity available at the IOD 200, the capabilities available at the IOD 200, the processing power available at the IOD 200, and the storage capacity at the IOD 200. Thus, the IOD 200 can either filter the received modified beacon signal, thereby making a decision as to whether the beacon signal should be considered by the IODH 300, or add the corresponding parameters to the received modified beacon signal before it is forwarded to the IODH 300, so that the IODH 300 also considers the parameter when determining how to adapt the set of IOD 200a, IOD 200b, IOD 200c. Alternatively, the IOD 200 can apply a combination of both, such that some parameters are used in the filtering process while other parameters are forwarded to the IODH 300.

[0111] As described above, the IOD 200 can be configured to directly forward the received modified beacon signal or a portion of the received modified beacon signal to the IODH 300, or to an authenticator that is further configured to process the received modified beacon signal before it is forwarded to the IODH 300.

[0112] According to another embodiment, referring to Figure 8 an IOD 200′ is presented, wherein a receiving unit or communication unit 800 is configured to receive a beacon signal associated with an ongoing communication session and transmitted by a UT, corresponding to Figure 4 step 400; a determining unit 810 is configured to determine, at least in part based on the content of the received beacon signal, whether the received beacon signal is a modified beacon signal, whether the received beacon signal is to be forwarded to the IODH 300 or the IOD 200′ is to refrain from forwarding the modified beacon signal, corresponding to Figure 4the "Yes" branch of step 420b; and a forwarding unit 820 configured to forward at least a portion of the content of the received beacon signal to the IODH 300 when it is determined that the received beacon signal is a modified beacon signal and at least a portion of the content is to be forwarded, such that the IODH 300 can determine how the IOD 200' acts during the adaptation of at least one set of IODs 200'. The IOD 200' may further include a signal strength measurement unit 830 configured to determine the signal strength of the received modified or unmodified beacon signal, and when the IOD 200' is configured to filter the received beacon signal, the IOD 200' may further include a filtering unit 840 configured to perform such filtering according to any of the embodiments described herein.

[0113] Reference will now be made to Figure 9 the IODH configured to perform the method as disclosed herein will be described in further detail. The IODH 300 includes a processor circuitry 900 and a memory 910 including executable instructions configured to enable the IODH 300 to perform according to Figure 9 the method. The memory 910 may be any combination of random access memory (RAM) and / or read only memory (ROM). The memory 910 generally further includes a persistent storage device, which may be, for example, any single or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The processing circuitry 900 may include, for example, one or more central processing units (CPUs), a multiprocessor or a digital signal processor (DSP).

[0114] Computer-readable instructions configured to provide the functionality described herein may be provided as a computer program 950 configured in the form of a computer program product 960, where the computer program product 960 may be, for example, an optical disc such as a compact disc (CD), a digital versatile disc (DVD) or a Blu-ray disc.

[0115] More specifically, the IODH 300 is capable of adapting the connectivity of the UT 100 during an ongoing communication session provided by the service to the UT 100 via at least one of the IODs 200a, 200b. The IODH 300 includes a processor circuitry 900 configured to cause the IODH 300 to: receive, via a communication circuitry 920, information (hereinafter referred to as first information) from a first set of at least one of the IODs 200a, 200b, the information being associated with the ongoing communication session and received by the corresponding one or more of the IODs 200a, 200b from the UT 100, and determine an adaptation of the first set of at least one of the IODs 200a, 200b based on second information received from a second set of at least one of the IODs 200a, 200b, 200c and included in one or more modified beacon signals. Thereafter, the IODH 300 is configured to instruct, by the communication circuitry 900 based on the determined adaptation, one or more of the IODs 200a, 200b, 200c on how to participate in the adaptation of the first set of at least one of the IODs 200a, 200b. It should be understood that the first set of IODs and the second set of IODs may be fully, partially, or non-overlapping, considering that IODs may be removed, added, or replaced with each other.

[0116] According to one embodiment, the IODH 300 is configured to base the determination at least in part on the signal strength of one or more beacon signals received from a second set of at least one of the IODs 200a, 200b, 200c and included in the received second information.

[0117] The IODH 300 may be configured to determine the adaptation of the set of IODs 200a, 200b, 200c based on several different parameters included in the second information, either individually or in combination. Such parameters include, for example, a session identifier identifying the ongoing communication session; a beacon identifier indicating that the received signal is a beacon signal; a freshness parameter, which is a parameter updated each time a corresponding beacon signal is sent by the IODs 200a, 200b, 200c to distinguish one sent beacon signal from a previously sent beacon signal; an encryption proof of the originator, which provides at least partial encryption protection for the beacon signal; and the capability requirements for the ongoing communication session. Generally, the IODH 300 is configured to make the mentioned adaptation at least in part based on the combination of the second information received from multiple IODs 200a, 200b, 200c.

[0118] In addition to, or in combination with, what has been mentioned above, the IODH 300 may also be configured to perform a determination on how to adapt the IOD set at least in part based on: the signal strength of the beacon signals received by the respective IODs 200a, 200b, 200c; the battery capacity of the respective IODs 200a, 200b, 200c; the amount of processing power available in the respective IODs 200a, 200b, 200c, the amount of interface capacity available in the respective IODs 200a, 200b, 200c, and the amount of storage capacity available in the respective IODs 200a, 200b, 200c.

[0119] According to other embodiments, the IODH 300 is configured to also consider one or more of the following: the personal preferences of the user of the UT 100, and the estimated distance between the UT 100 and the respective IODs 200a, 200b, 200c, at least in part based on the received combined signal strength. Regarding the first alternative, such preferences may be provided in the modified beacon signal, or obtained from data stored at or accessible to the IODH 300, and the latter information may be determined by the IODH 300, or provided from one or more of the IODs 200a, 200b, 200c.

[0120] According to another aspect, reference is made to Figure 10 There is presented an IODH 300′, wherein the receiving or communication unit 1000 is configured to receive the information in the beacon signal, corresponding to Figure 4 step 400; the determination unit 1100 is configured to determine the adaptation of the first set of at least one IOD based on the second information included in one or more modified beacon signals received from a second set of at least one IOD, corresponding to Figure 4 step 430; and the instruction unit 1200 is configured to instruct one or more of the at least one IOD on how to participate in the adaptation of the first set of at least one IOD based on the determined adaptation, corresponding to Figure 4 step 440.

Claims

1. A method in a user tag UT for enabling adaptation of the connectivity of the UT during an ongoing communication session, the method comprises: - During the ongoing communication session, sending (200) a pre - beacon signal that is detectable by at least one IOD when the UT is located near the at least one IOD; - When determining (210) that adaptation of a set of at least one IOD is needed, modifying (220) the pre - beacon signal, wherein the modification includes: including in the beacon signal an indication requesting adaptation for the set of at least one IOD, and - Sending (230) the modified beacon signal such that one or more IODs located near the UT can participate in the adaptation of the set of at least one IOD.

2. The method according to claim 1, wherein the pre - beacon signal includes a transmission configuration, the transmission configuration including one or more of the following: - An indication of a power class applied by the UT when sending the pre - beacon signal, and - An indication of a maximum allowed transmission power level applied by the UT when sending the pre - beacon signal.

3. The method according to any one of the preceding claims, wherein during the modification (220), the beacon signal is included together with the following: - A session identifier identifying the ongoing communication session, and - A modification indicator indicating whether adaptation of the set of at least one IOD is requested.

4. The method according to claim 3, wherein during the modification (220), the beacon signal is further included together with at least one of the following the following: - A beacon identifier indicating that the signal is a beacon signal; - A freshness parameter, which is a parameter updated each time the UT sends the beacon signal, so as to distinguish one sent beacon signal from a previously sent beacon signal, - An encryption proof of the originator, which provides encryption protection for at least part of the beacon signal, and - An indication of the capability requirements for the ongoing communication session.

5. The method according to claim 4, wherein during the modification (220), the beacon signal is included together with the capability requirements, the capability requirements indicating requirements for at least one of the following: - Removing capabilities assigned to the ongoing communication session that the UT no longer needs in the ongoing communication session; - Adding capabilities that the UT needs in the ongoing communication session to the ongoing communication session, and - Replacing the capabilities assigned to the ongoing communication session with capabilities more suitable for the UT in the ongoing communication session than the currently used capabilities.

6. The method according to any one of claims 1 to 5, wherein the modified beacon signal is included together with at least one capability requirement.

7. The method according to claim 6, wherein the at least one capability requirement includes at least one of the following: screen, display, speaker, camera, microphone, mouse, keyboard, touchpad, inertial measurement unit (IMU), light source, sensor, and actuator.

8. The method according to any one of the preceding claims, wherein the modification (220) of the beacon signal is based on at least one of the following: - detecting that a user interaction detectable by the UT has been performed, the user interaction indicating a request for adaptation of the set of at least one IOD; - detecting that the UT is located at a specific geographical location where adaptation of the set of at least one IOD is required; - detecting that a specific time instance has arrived at which adaptation of the set of at least one IOD is required; - detecting that a specific time interval during which adaptation of the set of at least one IOD is required has started or expired, and - detecting that a specific event detectable by the UT and requiring adaptation of the set of at least one IOD has occurred.

9. The method according to any one of the preceding claims, comprising a further step of repeating N times the sending (230) of at least a portion of the modified beacon signal.

10. The method according to claim 9, wherein for each of the N repetitions, after initially sending (230) the modified beacon signal with an unchanged transmission power and then sending another modified beacon with a transmission power reduced or increased by a predetermined amount, the transmission power is reduced or increased by a predetermined second amount.

11. The method according to any one of claims 9 or 10, wherein the initially modified beacon signal further includes a transmission plan related to the N modified beacon signals for subsequent repetitions.

12. The method according to any one of claims 8 to 11, wherein the modified beacon signal is included together with a modification indicator, and wherein the modification indicator is set only during the initially modified beacon prior to the N modified beacon signals.

13. A method in an input / output device manager IODH for adapting the connectivity of a user tag UT during an ongoing communication session IOD, the method comprises: - receiving (400) from a first set of at least one IOD first information in a respective beacon signal associated with the ongoing communication session and received by the respective one or more IODs from the UT; - determining (430) the adaptation of the first set of at least one IOD based on (410) second information received from a second set of at least one IOD and included in one or more modified beacon signals, and - instructing (440) one or more IODs of the at least one IOD how to participate in the adaptation of the first set of at least one IOD based on the determined adaptation.

14. The method according to claim 13, wherein the determination (430) is at least partially based on the signal strength of one or more beacon signals received by the second set of at least one IOD and included in the received second information.

15. The method according to any one of claims 13 to 14, wherein the determination (430) is based on at least one of the following included in the second information received from the second set of the at least one IOD: - A session identifier identifying the ongoing communication session; - A beacon identifier indicating that the received signal is a beacon signal; - A freshness parameter, which is a parameter updated each time an IOD transmits a corresponding beacon signal, so as to distinguish one transmitted beacon signal from a previously transmitted beacon signal; - An encryption proof of the initiator, which provides encryption protection for at least part of the beacon signal, and - A capability requirement for the ongoing communication session.

16. The method according to any one of claims 13 to 15, wherein the adaptation of the first set of the at least one IOD is determined (430) at least in part based on the combination of the received second information.

17. The method according to any one of claims 13 to 16, wherein the determination (430) is further at least in part based on at least one of the following included in each second information: - The signal strength of the beacon signal received with the corresponding IOD battery capacity of the corresponding IOD; - The amount of processing power of the corresponding IOD, and - The amount of storage capacity available at the corresponding IOD.

18. The method according to any one of claims 16 or 17, wherein the determination (430) is at least in part based on at least one of the following: - The personal preferences of the user of the UT, and - The estimated distance between the UT and the corresponding IOD, which is at least in part based on the received combined signal strength.

19. A method in a first input / output device IOD for operating during an ongoing communication session to adapt connectivity, the method comprises: - Receiving (300) a beacon signal associated with the ongoing communication session and transmitted by the UT; - Determining (310) at least in part based on the content of the received beacon signal whether the received beacon signal is a modified beacon signal, whether the received beacon signal is to be forwarded (450) to the input / output device manager IODH or to be blocked (440) from forwarding, and - In the case where it is determined that the received beacon signal is a modified beacon signal and at least a part of the content of the received beacon signal is to be forwarded, forwarding (450) at least a part of the content to the IODH, so that the IODH can determine how the first IOD acts during the adaptation of the set of the at least one IOD.

20. The method according to claim 19, wherein the IOD obtains an indication of the signal strength of the beacon signal when it is received by the IOD.

21. The method according to any one of claims 19 or 20, wherein the received beacon signal is forwarded (450) only if the filtering criteria for forwarding the received beacon signal are met.

22. The method according to claim 21, wherein the filtering criteria are based on at least one of the following: - The signal strength of the received beacon signal; - The remaining battery capacity of the IOD; - The capabilities available at the IOD; - The amount of processing power available at the IOD, and - The amount of storage capacity available at the IOD.

23. The method according to any one of claims 19 to 22, wherein information about at least one of the following is included with the forwarded beacon signal : - The signal strength of the received beacon signal; - The battery capacity of the IOD; - The capabilities available at the IOD; - The processing power available at the IOD, and - The storage capacity available at the IOD.

24. The method according to any one of claims 19 to 23, wherein at least a portion of the content of the received beacon signal is forwarded (450) via an authenticator to the IODH.

25. A user tag UT (100) for enabling adaptation of the connectivity of the UT (100) during an ongoing communication session, the UT (100) comprising processing circuitry (500) configured to cause the UT (100) to: - During the ongoing communication session, send a previous beacon signal that is detectable by at least one IOD (200a, 200b, 200c) when the UT (100) is located near the at least one IOD (200a, 200b, 200c); - Modify the previous beacon signal when it is determined that adaptation of a set of the at least one IOD (200a, 200b, 200c) is needed, wherein the modification comprises: Indicating to the beacon signal a request for adaptation of the set of the at least one IOD (200a, 200b, 200c), and - Sending the modified beacon signal such that one or more IODs (200a, 200b, 200c) located near the UT (100) can participate in the adaptation of the set of the at least one IOD (200a, 200b, 200c).

26. The UT (100) according to claim 25, further configured to send the previous beacon signal including a transmission configuration, the transmission configuration including one or more of the following: - An indication of the power class applied by the UT (100) when sending the previous beacon signal, and - An indication of the maximum allowable transmission power level applied by the UT (100) when sending the previous beacon signal.

27. The UT (100) according to any one of claims 25 or 26, further configured to include, together with the beacon signal during modification : - A session identifier identifying the ongoing communication session, and - A modification indicator indicating whether adaptation of the set of the at least one IOD (200a, 200b, 200c) is requested.

28. The UT (100) according to claim 27, further configured to, during modification, include the beacon signal together with at least one of the following including: - a beacon identifier indicating that the signal is a beacon signal, - a freshness parameter, which is a parameter updated each time the UT (100) transmits the beacon signal, so as to distinguish one transmitted beacon signal from a previously transmitted beacon signal, - an encryption proof of the initiator, which provides encryption protection for at least part of the beacon signal, and - an indication of the capability requirements for the ongoing communication session.

29. The UT (100) according to claim 28, further configured to, during modification, include the beacon signal together with the capability requirements, the capability requirements indicating requirements for at least one of the following: - removing capabilities assigned to the ongoing communication session that the UT (100) no longer needs in the ongoing communication session; - adding capabilities that the UT (100) needs in the ongoing communication session to the ongoing communication session, and - replacing the capabilities assigned to the ongoing communication session with capabilities more suitable for the UT (100) in the ongoing communication session than the currently used capabilities.

30. The UT (100) according to any one of claims 25 to 29, further configured to include the modified beacon signal together with at least one capability requirement.

31. The UT (100) according to claim 30, further configured to include including the modified beacon signal together with at least one capability requirement, the at least one capability requirement including at least one of the following: screen, display, speaker, camera, microphone, mouse, keyboard, touchpad, inertial measurement unit (IMU), light source, sensor, and actuator.

32. The UT (100) according to any one of claims 25 to 31, further configured to modify the beacon signal based on at least one of the following: - detecting that a user interaction detectable by the UT (100) has been performed, the user interaction indicating a request for adaptation of the set of at least one IOD (200a, 200b, 200c); - detecting that the UT (100) is located at a specific geographical location where adaptation of the set of at least one IOD (200a, 200b, 200c) is required; - detecting that a specific time instance when adaptation of the set of at least one IOD (200a, 200b, 200c) is required has arrived; - detecting that a specific time interval when adaptation of the set of at least one IOD (200a, 200b, 200c) is required has started or expired, and - detecting that a specific event detectable by the UT (100) and requiring adaptation of the set of at least one IOD has occurred.

33. The UT (100) according to any one of claims 25 to 32, further configured to repeat at least a part of the transmission of the modified beacon signal N times.

34. The UT (100) according to claim 33 is further configured such that, for every N repetitions, after an initial modified beacon signal has been transmitted using an unchanged transmission power and another modified beacon has been transmitted using a transmission power reduced or increased by a predetermined amount, the transmission power is reduced or increased by a predetermined second amount.

35. The UT (100) according to any one of claims 33 or 34 is further configured to provide a transmission plan related to the N modified beacon signals for subsequent repetitions to the initial modified beacon signal.

36. The UT (100) according to any one of claims 29 to 35 is further configured to include the modified beacon signal together with a modification indicator and set the modification indicator only during the initial modified beacon before the N modified beacon signals.

37. An input / output device manager IODH (300) capable of adapting the connectivity of a user tag UT (100) during an ongoing communication session, the IODH (300) including a processor circuitry (900), the processor circuitry (900) being configured to cause the IODH (300) to: - Receive first information in a corresponding beacon signal received from the UT (100) by a respective one or more IODs (200a, 200b, 200c) from a first set of at least IODs (200a, 200b, 200c) associated with the ongoing communication session; - Determine the adaptation of the first set of at least one IODs (200a, 200b, 200c) based on second information received from a second set of at least one IODs (200a, 200b, 200c) and included in one or more modified beacon signals, and - Based on the determined adaptation, instruct one or more of the at least one IODs (200a, 200b, 200c) how to participate in the adaptation of the first set of at least one IODs (200a, 200b, 200c).

38. The IODH (300) according to claim 37 is further configured to make the determination at least in part based on the signal strength of one or more beacon signals received by the second set of at least one IODs (200a, 200b, 200c) and included in the received second information.

39. The IODH (300) according to any one of claims 37 to 38 is configured to determine the adaptation based on at least one of the following included in the second information received from the second set of at least one IODs (200a, 200b, 200c): - A session identifier identifying the ongoing communication session; - A beacon identifier indicating that the received signal is a beacon signal; - A freshness parameter, which is a parameter updated each time a corresponding beacon signal is sent by an IOD (200a, 200b, 200c) to distinguish a sent beacon signal from a previously sent beacon signal; - An encryption proof of the initiator, which provides encryption protection for at least part of the beacon signal, and - A capability requirement for the ongoing communication session.

40. The IODH (300) according to any one of claims 37 to 39 is further configured to: At least partly base the adaptation of the first set of the at least one IOD (200a, 200b, 200c) on the combination of the received second information.

41. The IODH (300) according to any one of claims 37 to 40 is configured to further perform the determination at least partly based on at least one of the following included in each second information: - The signal strength of the beacon signal received by the corresponding IOD (200a, 200b, 200c); - The battery capacity of the corresponding IOD (200a, 200b, 200c); - The amount of processing power available in the corresponding IOD (200a, 200b, 200c), and - The amount of storage capacity available in the corresponding IOD (200a, 200b, 200c).

42. The IODH (300) according to claim 40 or 41 is configured to perform the determination at least partly based on at least one of the following: - The personal preference of the user of the UT (100), and - The estimated distance between the UT (100) and the corresponding IOD (200a, 200b, 200c) based at least partly on the received combined signal strength.

43. An input / output device IOD (200) capable of functioning in adapting connectivity during an ongoing communication session, the IOD (200) including processing circuitry configured to cause the IOD (200) to: - Receive a beacon signal associated with the ongoing communication session and sent by the UT (100); - Determine, at least partly based on the content of the received beacon signal, whether the received beacon signal is a modified beacon signal, whether the received beacon signal is to be forwarded to an input / output device manager IODH (300), or whether the IOD (200) is to refrain from forwarding the modified beacon signal, and - In the case where it is determined that the received beacon signal is a modified beacon signal and at least part of the content of the received beacon signal is to be forwarded, forward at least part of the content to the IODH (300) so that the IODH (300) can determine how the IOD (200) acts during the adaptation of the set of the at least one IOD (200).

44. The IOD (200) according to claim 43 is further configured to obtain an indication of the signal strength of the beacon signal when it is received by the IOD (200). The IOD (200) according to any one of claims 43 or 44 is further configured to forward the received beacon signal only if a filtering criterion for forwarding the received beacon signal is satisfied.

46. The IOD (200) according to claim 45, wherein the IOD (200) is configured to make the filtering criterion based on at least one of the following: - The signal strength of the received beacon signal; - The battery capacity of the IOD (200); - The capabilities available at the IOD (200); - The processing power available at the IOD (200), and - The storage capacity available at the IOD (200).

47. The IOD (200) according to any one of claims 43 to 46 is further configured to include at least one of the following together with the forwarded beacon signal: - The signal strength of the received beacon signal; - The battery capacity of the IOD (200); - The capabilities available at the IOD (200); - The processing power available at the IOD (200), and - The storage capacity available at the IOD (200).

48. The IOD (200) according to any one of claims 43 to 47 is further configured to forward at least a portion of the content of the received beacon signal to the IODH (300) via an authenticator.

Images