Patent Application
20220094723
The invention relates to a device configured as user equipment (UE2) for a mobile network and for delivering content to another user equipment (UE1), and to a computer-implemented method for delivering content to the other user equipment. The invention further relates to a device configured as user equipment (UE1) for a mobile network and for receiving content from another user equipment (UE2), and to a computer-implemented method for receiving content from the other user equipment. The invention further relates to the mobile network, and to a computer program comprising instructions for causing a processor system to perform either method.
A large part of the traffic on the Internet and on mobile networks is generated by content distribution, in particular distribution of audiovisual media such as video. For many years, Content Delivery Networks (CDNs) have been used to make distribution of video more efficient. CDNs build on the observation that many viewers want to see the same video. By caching (i.e., storing copies of) popular content at different locations (both geographically and in terms of the network topology), the total amount of traffic may be reduced. At the same time, CDNs may improve the delivery quality as, in general, the network routes between the nodes that play out content and the viewer's device become shorter as more caches are added in the network. It is noted that CDNs are generally considered as overlay networks that depend on one or more underlying networks to transport the content to its destination. The underlying networks may thus be considered to support the CDN or be part of the CDN.
Although CDNs originate from content delivery over fixed networks, they have become relevant for content delivery to mobile devices (also referred to as User Equipment, or in short UE) as well. Such UEs may have the possibility to cache content and make the cached content available to other UEs seeking the same content.
3GPP has formulated requirements on ‘Efficient content delivery’ in TS 22.261 [1]. This includes requirements on caches close or on UEs, such as:
There is thus a general need to improve content delivery between UEs.
Mobile devices may establish connections to other UEs via a mobile network infrastructure, but also via Device-to-Device (D2D) communication.
GB2537623 [2] describes a content delivery method employing a plurality of transient device-to-device (D2D) links among User Equipments (UEs) in the vicinity of a content-seeking UE and which locally cache desired content. To obtain the desired content, successive D2D links are initiated by the content-seeking UE with initial guidance from a central Femto network controller. The central Femto network controller identifies possible D2D content donor UEs in the vicinity of the content-seeking UE and indicates a probability of successfully obtaining the content through UE-orchestrated content delivery using multiple D2D links. A user then decides whether to attempt UE-orchestrated content delivery or whether to obtain the content in another way.
GB2537623, however, does not describe how to establish the D2D connection if the user decides to attempt UE-orchestrated content delivery.
[1] 3GPP TS 22.261 V16.5.0 (2018 September), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 16).
[2] Content delivery over D2D links, GB2537623
It would be desirable to obtain a mechanism to enable a D2D connection to be established to a UE which is identified as content donor, for example by a CDN.
In accordance with a first aspect of the invention, a device is provided which may be configured as user equipment (UE2) for a mobile network and which may be configured for delivering content to another user equipment (UE1).
The device may comprise:
In accordance with a further aspect of the invention, a device is provided which may be configured as user equipment (UE1) for a mobile network and which may be configured for requesting and receiving content from another user equipment (UE2).
The device may comprise:
In accordance with a further aspect of the invention, a computer-implemented method may be provided for delivering content to a user equipment (UE). The method may comprise:
In accordance with a further aspect of the invention, a computer-implemented method may be provided for a user equipment (UE1) to request and receive content from another user equipment (UE2). The method may comprise:
In accordance with a further aspect of the invention, a transitory or non-transitory computer-readable medium may be provided comprising a computer program. The computer program may comprise instructions for causing a processor system to perform one of the computer-implemented methods.
The above measures may involve a device, which is also referred to as UE1 or recipient UE, requesting and receiving content from another device, which is also referred to as UE2 or donor UE. The delivery of the content may at least in part take place via D2D communication between the donor UE and the recipient UE.
For that purpose, the recipient UE may send a request for content delivery to the donor UE. This request may be sent via the mobile network, e.g., via part of the mobile network, and thereby using the mobile network's infrastructure. Here, the term ‘mobile network’ (also known as wireless network) may refer to a telecommunication network which may service mobile UEs, but in some cases also fixed UEs. The identification of the donor UE as having the content requested by the recipient UE may be performed using known techniques. For example, if the donor UE functions as a cache in a CDN, the donor UE may be identified using known a CDN mechanism, e.g., using a DNS of the CDN.
To enable a D2D connection to be established between the recipient UE and the donor UE, the recipient UE may include its D2D communication identifier in the content request. The content request itself may be based on a known type of content request, e.g., a GET request, to which the D2D communication identifier may be added. Such a D2D communication identifier is known per se, and may also be referred to as D2D (link) ID. The donor UE receiving the content request may thus be provided with the D2D communication identifier of the recipient UE, and may use this D2D communication identifier to establish the D2D connection with the recipient UE, if such a connectivity type is selected by the donor UE for content delivery.
Having established the D2D connection with the recipient UE, all or at least part of the requested content may then be delivered via D2D communication, while at the receiving side, the recipient UE may identify whether the content delivered via the D2D connection represents an at least partial fulfillment of the content request.
The above measures have the effect that an existing mechanism for a recipient UE to request content from a donor UE may be extended with functionality to allow the donor UE to deliver the content at least in part via D2D communication to the recipient UE. Specifically, by including the D2D communication identifier in the content request, said identifier may be provided to the donor UE in a reliable and efficient manner. The identification of the donor UE and the transmission of the content request to the donor UE itself may involve existing techniques, for example those known from content delivery networks, and may use the existing mobile network infrastructure. To be able to select D2D communication for content delivery, the functionality of the donor UE may be extended to select between the different connectivity types. Thereby, an efficient mechanism may be provided for enabling content delivery from a donor UE to a recipient UE to take place at least in part via D2D communication.
D2D communication may be established using techniques such as the Proximity-based Services (ProSe) framework [3] (see also ‘Further References’). It is noted that ProSe may allow UEs to find other UEs in their proximity with relevant applications. In standard ProSe, this may involve UEs announcing applications they have or seek, and UEs monitoring the announcements from other UEs. As a part of the announcing of applications, or as a follow-up step, UEs may also specify the content they are seeking or have available. However, in ProSe, the donor UE may have to be discovered ‘bottom up’ again from such announcements by potential donor UEs on applications and (optionally as a part or follow up) content they have available and from announcements by seeking UEs on the content they prefer. It may also happen that a donor UE is discovered that announces an application but doesn't have the content that the recipient UE needs. Compared to the above described measures by which the donor UE is identified and provided with the content request of the recipient UE via the mobile network, this may introduce an inefficient second round of UE discovery before the D2D connection may be established. This inefficiency may be in contradiction with the 3GPP goal for efficient content delivery.
Advantages of the above measures may include, but are not limited to, avoidance of the lengthy discovery request procedures (announce/monitor) of standard ProSe, which may save radio, battery and processing resources at the UEs. In addition, the above measures may provide a distributed architecture for D2D connection setup, e.g., without central elements, which may make the approach independent from the mobile network architecture and therefore more scalable. Furthermore, decisions on the type of connectivity may be made locally at the donor UE (rather than the recipient UE), which may make it possible to take into account the donor UE resources already in use for content distribution to other UEs. This may be particularly relevant if the donor UE serves a larger number of recipient UEs.
The following embodiments relate to the device, and mutatis mutandis to the corresponding computer-implemented method, for delivering content to a recipient UE, but may denote complementary limitations in the processor system and computer-implemented method for requesting and receiving the content.
In an embodiment, the content request may comprise a content identifier which identifies the content requested by the other user equipment (UE1), and the processor subsystem may be configured to provide the content identifier to the other user equipment (UE1) via the D2D connection. The content identifier may allow the recipient UE1 to efficiently identify whether the content delivered via the D2D connection represents an at least partial fulfillment of the content request. Thereby, the identification of the (partial) fulfillment of the content request may be facilitated.
In an embodiment, the processor subsystem may be configured to acknowledge the content request by sending a response to the other user equipment (UE1) via the mobile network, wherein the response may be indicative of the selected connectivity type. The donor UE may select a connectivity type, which may comprise delivery via the mobile network, delivery via D2D communication, and in some embodiments, a combination of both connectivity types. By explicitly or at least implicitly identifying the connectivity type to the recipient UE, the recipient UE may determine if content delivery involves D2D communication, and if so, the recipient UE may be prompted to cooperate in establishing the D2D connection with the donor UE. Otherwise, such a D2D connection may in some cases be refused by the recipient UE, e.g., based on a security policy. Additionally or alternatively, the identification of the connectivity type may enable the recipient UE to better match the content delivered via a particular connectivity type to a (partial) fulfillment of the content request.
In an embodiment, the processor subsystem may be configured to select between the connectivity types based on metadata which may be indicative of a technical feasibility of content delivery using the D2D connection. D2D communication typically relies on a proximity of the donor UE to the recipient UE, and vice versa. D2D communication may not be technically feasible if both UEs are not proximate, and/or for a number of other reasons. In many cases, metadata is or may be made available which may be indicative of the technical feasibility of D2D communication, or specifically of content delivery via a D2D connection. Accordingly, the donor UE may select the most appropriate connectivity type on the basis of such metadata.
In an embodiment, the metadata may comprise at least one of the group of:
Such metadata has been found to be indicative of the technical feasibility of content delivery from the donor UE to the recipient UE via D2D communication.
In an embodiment, at least part of the metadata may be received from at least one of the group of:
At least some of the metadata may be provided by the recipient UE and/or by an entity in the mobile network. For example, the recipient UE may report its location, resource availability, signal strength, experienced QoS and/or battery level to the donor UE. Another example is that the mobile network may report an absolute location of the recipient UE to the donor UE, or a location relative to the donor UE.
In an embodiment, the processor subsystem may be configured to determine if a D2D connection to the other user equipment (UE1) already exists, and if there is an existing D2D connection, reuse the existing D2D connection. In some cases, it may not be needed to establish a D2D connection to the recipient UE, namely if such a D2D connection has already been established, e.g., for a previous delivery of content, or for another reason not related to content delivery per se.
In an embodiment, the connectivity types may further comprise delivery of the content using the mobile network and using D2D communication. For example, part of the content may be delivered via the mobile network, while another part of the content may be delivered via D2D communication. This may, for example, allow faster content delivery compared to delivery using only one of the connectivity types.
In an embodiment, a mobile network may comprise the above-mentioned device, and the mobile network may be configured to establish at least part of a content delivery network and the device may be a cache in the content delivery network.
The following embodiments relate to the device, and mutatis mutandis to the corresponding computer-implemented method, for requesting and receiving content from the donor UE, but may denote complementary limitations in the processor system and computer-implemented method for delivering the content.
In an embodiment, the content request may comprise a first content identifier which identifies the content which is requested, and the processor subsystem may be configured to identify whether the content delivered via the D2D connection represents the at least partial fulfillment of the content request by comparing the first content identifier to a second content identifier which is provided by the other user equipment (UE2) via the D2D connection. By the donor UE providing a content identifier identifying the delivered content to the recipient UE, and the recipient UE comparing this content identifier to a content identifier of the requested content, the recipient UE may determine whether the content delivered via the D2D connection represents an at least partial fulfillment of the content request.
In an embodiment, the user equipment (UE1) may be configured to receive a response from the other user equipment (UE) via the mobile network, wherein the response represents an acknowledgement of the content request and comprises a D2D communication identifier of the other user equipment (UE2), and the processor subsystem may be configured to identify whether the content delivered via the D2D connection represents the at least partial fulfillment of the content request based on the D2D connection being established to an entity having a D2D communication identifier which matches the D2D communication identifier of the other user equipment (UE2). The donor UE may acknowledge the content request, e.g., using a known response mechanism, such as sending a GET response. By including the D2D communication identifier of the donor UE in the response, the recipient UE may associate the D2D connection, and thereby content delivered via the D2D connection, with the content request which has been sent to the donor UE. This may allow the recipient UE to determine whether the content delivered via the D2D connection represents an at least partial fulfillment of the content request.
In an embodiment, the processor subsystem may be configured to include metadata in the content request which is indicative of a technical feasibility of the D2D connection. Such metadata may allow the donor UE to determine a technical feasibility of content delivery via the D2D connection. Examples of such metadata include, but are not limited, to location data, resource availability data, signal strength data, data indicative of an experienced QoS and/or battery level data of the recipient UE.
In an embodiment, the content request may be for a content segment, and the processor subsystem may be configured to send further content requests for further content segments to the further user equipment (UE2) via the D2D connection. Once the D2D connection is established, following content requests may be sent directly to the donor UE via the D2D connection, instead of being sent via the mobile network.
In accordance with a further aspect of the invention, a transitory or non-transitory computer-readable medium may be provided comprising structured data representing a content request. The content request may comprise at least one of the group of:
It will be appreciated by those skilled in the art that two or more of the above-mentioned embodiments, implementations, and/or aspects of the invention may be combined in any way deemed useful.
Modifications and variations of any one of the devices or UEs, methods and/or the computer programs, which correspond to the described modifications and variations of another device or UE, method or computer program, may be carried out by a person skilled in the art on the basis of the present description.
[3] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Proximity-based services (ProSe); Stage 2 (Release 15), 3GPP TS 23.303 V15.1.0 (2018 June)
These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter. In the drawings,
It should be noted that items which have the same reference numbers in different figures, have the same structural features and the same functions, or are the same signals. Where the function and/or structure of such an item has been explained, there is no necessity for repeated explanation thereof in the detailed description.
The following list of references and abbreviations is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims.
CDN content delivery network
D2D device-to-device
DNS domain name server
IP internet protocol
NAT network address translation
UE1, UE2 user equipment
URI Uniform Resource Identifier
URL Uniform Resource Location
1 resolve (content URL)
2 response (IP address of UE2)
3, 3a, 3b get (content URI, D2D ID UE1, geo)
3′ get (content URI, D2D ID UE1, geo, metrics)
4 select connectivity type
4
a response (content URI, D2D ID UE2, connectivity type)
5 D2D setup (D2D ID UE1, content URI)
5′ D2D setup (D2D ID UE1, content URI, D2D ID UE2)
5″ D2D setup (D2D ID UE1)
6 identify relation between get and D2D setup
6′ content transfer (content URI)
7 content transfer
7′ identify relation between get and content transfer
8 get (further content URI)
9 select connectivity type
10 content transfer (further content URI)
11 identify relation between get and content transfer
20 mobile network infrastructure
40 content delivery network system
42 domain name server
100 user equipment 1
120 network interface to mobile network
140 D2D communication interface
160 processor subsystem
200 user equipment 2
220 network interface to mobile network
240 D2D communication interface
260 processor subsystem
280 cache
300 content request data structure
400 method for delivering content
410 receiving content request via mobile network
420 selecting connectivity type
430 establishing D2D connection
440 delivering content using D2D connection
500 method for requesting and receiving content
510 sending content request via mobile network
520 receiving content via D2D connection
530 identify whether content request is fulfilled
600 computer readable medium
610 non-transitory data
1000 exemplary data processing system
1002 processor
1004 memory element
1006 system bus
1008 local memory
1010 bulk storage device
1012 input device
1014 output device
1016 network adapter
1018 application
The following embodiments relate to content delivery from a donor UE (also referred to as UE2 or donor UE2) to a recipient UE (also referred to as UE1 or recipient UE), and may generally involve the recipient UE sending a content request to the donor UE via a mobile network while including a D2D communication identifier of the recipient UE in the content request. The D2D communication identifier may be used by the donor UE to select and establish a D2D connection to the recipient UE, e.g., if technically feasible, and deliver the content at least in part via the D2D connection.
It is noted that while the following embodiments are described within the context of the donor UE representing a cache in a content delivery network (CDN) and being identified to the recipient UE using the CDN, and in particular using a domain name server (DNS) of the CDN, the use of a CDN is not a requirement, in that other known mechanisms which can translate content identifiers or names to one or multiple content locators may be used instead for enabling the recipient UE to send a request for content via a mobile network to a donor UE offering the content. For example, HTTP URL Redirection may be used or even a direct content request, for example based on static configuration, between UEs via the mobile network, is not precluded. The following measures are therefore not limited to CDN systems.
As previously indicated, the donor UE (UE2, 200) may be considered to be ‘part’ of a CDN system 40, in the sense that UE2200 may cache content from the CDN system 40. UEs that seek content, such as the depicted recipient UE (UE1, 100), may obtain information from the CDN system 40 on an optimal network node offering the content and the route to that network node through standard CDN procedures, e.g. based on a DNS 42 resolving a content URL to an IP address of the network node. The DNS 42 may be partly outside (not shown) and partly inside the CDN system 40. It is noted that a DNS Query based on a content URL is one of the mechanisms that CDNs may use, but others exist as well and may be used instead of such a DNS Query.
UE1 and UE2 may each have mobile network connectivity, enabling data communication via the mobile network infrastructure 20, with such type of data communication being indicated with dashed line arrows in
The embodiment shown in
1. UE1 may need content which is identified by a content URI. From the content URI, a content URL may be derived using existing approaches. Typically, the URL may be contained inside the content URI. In step 1, UE1 may send a DNS query to the DNS 42 using a message labeled ‘Resolve (content_url)’ to identify a network node that has the desired content.
2. The DNS 42 may return the IP address of UE2 using a message labeled ‘Response (IP address of UE2)’. The IP address may be a public or private IP address. Instead of an IP address, another type of network address may be used as well.
3. UE1 may send a Get request for the content to UE2 via a connection over the mobile network infrastructure 20. The Get request, which is labeled ‘Get (content URI, D2D ID UE1, geo)’, may include geolocation data of UE1 (e.g., its GPS location, as also discussed elsewhere) and its D2D communication identifier.
4. Upon receipt of the request, UE2 may select the type of connectivity to be used for the delivery of the content to UE1, as represented in
5. UE2 may set up a D2D connection to UE1 using message(s) labeled ‘D2D Setup (D2D ID UE1, content URI)’. For that purpose, UE1 may be identified in ProSe by its D2D communication identifier, using ProSe one-to-one communication (e.g., according to TS 23.303 [3] section 5.4.5). This may not need to involve any ProSe discovery steps. UE2 may include the content URI in the setup message(s).
6. UE1 may identify that the D2D connection which is being set up, or which has been setup is related to its earlier Get request, for example based on the content URI sent by UE2, see the arrow labeled ‘Identify relation between Get and D2D Setup’. As such, this step may overlap in time step 5, or may be performed afterwards.
7. The content may be transferred (also referred as ‘delivered’) from UE2 to UE1 via the established D2D connection, see the arrow labeled ‘Content transfer’.
It will be appreciated that while steps 1 and 2 may involve the use of existing CDN systems and procedures, UE1 may now be extended in terms of functionality, compared to known UEs interacting with CDN and similar systems, to include a D2D communication identifier in the content request (step 3), while UE2 may be extended with functionality to select the connectivity type (step 4) and to establish the D2D connection using the received D2D communication identifier of UE1 (step 5). Furthermore, UE1 may be extended with functionality to identify the relation between the earlier content request and the D2D connection which is (being) set up (step 6).
In yet another embodiment, there may be additional messages exchanged between UE1 and UE2, e.g., as extensions to the Get and response messages 3, 4a described above, which may contain information on the progress of the selection carried out by UE2 in step 4, or which may provide a confirmation of the receipt of the Get message by UE2, or a further confirmation of the response message 4a by UE1.
Such types of information may be obtained in the form of metadata. For example, metadata pertaining to UE1 may be provided by UE1 in an additional metrics data structure in the Get message in step 3′ (a modified version of step 3 of the embodiment of
UE2 may use such type of information to select the connectivity type. This may involve the use of a rule-based system, e.g., applying thresholds to metrics or comparing metrics between UE1 and UE2. Various other types of selection mechanisms are equally conceivable. For example, a machine learned model may be used to select an appropriate connectivity type based on said information as input.
In general, content may be split in several sequential segments. The segments may for example be time sequential, e.g., forming a video stream or an audio stream. After UE1 has received a first content segment (which may also be simply considered ‘content’), it may therefore request a further content segment (which may also be considered ‘further content’) according to the procedures described above.
The following describes embodiments with continued reference to
In an embodiment, the CDN system 40 may return a list of IP addresses of potential donor UEs rather than a single IP address in the response of step 2, or otherwise identify a number of donor UEs. The list may have an order that indicates the preference or priority for the IP addresses and thereby the donor UEs to be used by UE1. UE1 may try to approach the donor UEs with a Get message (step 3) in the indicated order or determine the preferred order by itself. As such, if a donor UE proves to be unreachable by UE1, UE1 may attempt to reach alternative donor UEs.
If in step 3 UE2 receives a request for content that UE2 has already received a request for within a given predetermined timeframe, UE2 may decide in step 4 to use a D2D one-to-many communication mode (e.g., a broadcast communication mode) to efficiently deliver the content to multiple recipient UEs. In particular, the D2D one-to-many communication may save radio resources compared to multiple D2D one-to-one communications. An example situation is a stadium case where many people wish to see the same content at or around the same time. The D2D one-to-many communication may be implemented using the One-to-many ProSe Direct Communication procedures from TS 23.303 [3] section 5.4 but also via other methods. In an embodiment, UE2 may wait for a predetermined time after receiving the Get request in step 3 for further UEs requesting the same content to determine whether one-to-many communication should be used. In another embodiment, UE2 may terminate one-to-one communication with a first UE and set up one-to-many communication with that first UE and another UE which requests the same content.
In an embodiment, UE2 may decide to use both a D2D connection and a connection over the mobile network to transfer the content to UE1. This may provide a higher bandwidth and may increase the stability of the overall connectivity between UE1 and UE2. The D2D connection may be set up using the procedures described above, while the connection over the mobile network may be set up using, e.g., the procedures described in 3GPP standards. The connections may be used in combination using standard channel bonding or link aggregation techniques.
In an embodiment, the geographical location of UE1 that may be sent by UE1 to UE2 in step 3 may be obtained from a Global Positioning System (GPS) or equivalent (Galileo, Glonass) function implemented on UE1. In an alternative embodiment, the location may be obtained from the mobile network, which may have a view on the approximate location of the UEs based on the cells they are in. The method for obtaining the location of UE1 may be based on the ProSe procedures for UE Location Reporting from TS 23.303 [3] section 5.5.6, in which the UEs report their locations to SLPs (SUPL Location Platforms) which in turn report the locations to ProSe functions. Through these procedures, UE2 may be informed of the geographical proximity of UE1 based on sources in the mobile network. This approach may be used if for example UE1 has no GPS or equivalent function, or no GPS fix.
The performance of the D2D connection may deteriorate, e.g., if the distance between UE1 and UE2 increases due to movement or if obstacles affect the transmission of radio signals. In an embodiment, upon detecting a deterioration that exceeds a certain threshold, UE2 may decide to terminate the use of the D2D connection and deliver the content to UE1 via a connection over the mobile network.
It will be appreciated that, in general, the operations or steps of method 400 of
It is noted that any of the methods described in this specification, for example in any of the claims, may be implemented on a computer as a computer implemented method, as dedicated hardware, or as a combination of both. Instructions for the computer, e.g., executable code, may be stored on a computer readable medium 600 as for example shown in
In an alternative embodiment of the computer readable medium 600 of
With continued reference to
In general, UE1 and UE2 may each be implemented at least in part by a device or apparatus. The device or apparatus may comprise one or more (micro)processors which execute appropriate software. Software implementing the functionality of the function(s) may have been downloaded and/or stored in a corresponding memory or memories, e.g., in volatile memory such as RAM or in non-volatile memory such as Flash. Alternatively, the function(s) may be implemented in the device or apparatus in the form of programmable logic, e.g., as a Field-Programmable Gate Array (FPGA). In general, each function may be implemented as a circuit.
The data processing system 1000 may include at least one processor 1002 coupled to memory elements 1004 through a system bus 1006. As such, the data processing system may store program code within memory elements 1004. Further, processor 1002 may execute the program code accessed from memory elements 1004 via system bus 1006. In one aspect, data processing system may be implemented as a computer that is suitable for storing and/or executing program code. It should be appreciated, however, that data processing system 1000 may be implemented in the form of any system including a processor and memory that is capable of performing the functions described within this specification.
Memory elements 1004 may include one or more physical memory devices such as, for example, local memory 1008 and one or more bulk storage devices 1010. Local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive, solid state disk or other persistent data storage device. The processing system 1000 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from bulk storage device 1010 during execution.
Input/output (I/O) devices depicted as input device 1012 and output device 1014 optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, for example, a microphone, a keyboard, a pointing device such as a mouse, a game controller, a Bluetooth controller, a VR controller, and a gesture-based input device, or the like. Examples of output devices may include, but are not limited to, for example, a monitor or display, speakers, or the like. Input device and/or output device may be coupled to data processing system either directly or through intervening I/O controllers. A network adapter 1016 may also be coupled to data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and/or remote storage devices through intervening private or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and/or networks to said data and a data transmitter for transmitting data to said systems, devices and/or networks. Modems, cable modems, and Ethernet cards are examples of different types of network adapter that may be used with data processing system 1000.
As shown in
In one aspect, for example, data processing system 1000 may implement the recipient UE (UE1). In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described herein with reference to the recipient UE. In another aspect, data processing system 1000 may implement the donor UE (UE2). In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described herein with reference to the donor UE.
In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb “comprise” and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article “a” or “an” preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list or group of elements represent a selection of all or of any subset of elements from the list or group. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
| Number | Date | Country | Kind |
|---|---|---|---|
| 19161190.4 | Mar 2019 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2020/055964 | 3/6/2020 | WO | 00 |
