Patent Description:
Computing tasks may be performed on a single processing unit, such as a processing core, or distributed over plural such units. A distributed computing model is applicable in particular, where the computing task may be divided into at least partly independent parts, such that the plural computing units can process aspects of the computing task in parallel, at least part of the time. Examples of the distributed processing model include cluster computing and grid computing. In grid computing, the processing units may be in general more distributed geographically, more heterogeneous in nature and configured to perform more heterogeneous aspects of the computing task than in cluster computing, where processing units may be configured to perform the same task. In general, the computing cluster and the computing grid are examples of distributed computation substrates.

Edge computing is a form of distributed computing, where elements of a distributed data processing substrate are disposed in a communication network, such that results of computing performed using the data processing substrate may be available to users of the communication network with lower latency, than the case where a data centre is located at a remote site in its entirety. In other words, in edge computing the computing is, at least partly, brought closer to where the results of the computing will be used.

Document <CIT> discloses multipath distributed computational node scenarios, wherein on-site and cloud-based calculation are combined by using broker and/or proxy nodes between a head node and worker nodes.

According to some aspects, there is provided the subject-matter of the independent claims. Some embodiments are defined in the dependent claims. The embodiments, examples and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

According to a first aspect of the present disclosure, there is provided an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to receive, when within a network environment of a master node of a distributed computation substrate, a computation work package addressed to a worker node, determine, after receiving the computation work package, that the apparatus has geographically moved to a network environment of the worker node or a broker node, wherein the network environment of the master node and the network environment of the worker node or the broker node are geographically separate and not communicatively coupled with each other, and forward the computation work package from the apparatus to the worker node while in the network environment of the worker node or to the broker node while outside the network environment of the master node.

According to a second aspect of the present disclosure, there is provided a method comprising receiving, by an apparatus, when within a network environment of a master node of a distributed computation substrate, a computation work package addressed to a worker node, determining, after receiving the computation work package, that the apparatus has geographically moved to a network environment of the worker node or a broker node, wherein the network environment of the master node and the network environment of the worker node or the broker node are geographically separate and not communicatively coupled with each other, and forwarding the computation work package from the apparatus to the worker node while in the network environment of the worker node or to the broker node while outside the network environment of the master node.

In a distributed computing substrate, some worker nodes of the distributed computing substrate may be outside a network environment of a master node of the distributed computing substrate. The network environment may comprise a mesh or ad hoc network, for example. As such, the master node would not be directly able to transmit work packages to such worker nodes. However, a broker node may be mobile, moving between a first position where it is within the network environment of the master node and a second position where it is within a network environment of the worker node. This enables the broker node to ferry work packages and results of the work between the master node and such worker nodes. Thus, as a technical effect, the distributed computing substrate need not form a continuously connected network environment and a utilization rate of computing resources may be enhanced, with less computing resources idle or out of use.

<FIG> illustrates an example system in accordance with at least some embodiments of the present invention. The system comprises a master node <NUM> of a distributed computation substrate, which may comprise a computation cluster or computation grid, for example. The master node may be a physical master node, or a logical master node comprised of plural physical units. The system further comprises worker nodes <NUM>, <NUM> and <NUM>. Master node <NUM> and worker nodes <NUM>, <NUM> are disposed in a network environment 100A of master node <NUM>. This network environment 100A may comprise a mesh or ad hoc network, or a combination of networks, for example an ad hoc network connected to the Internet. As such, for example worker node <NUM> may be in another country, and still be within network environment 100A. By the network environment 100A it is herein meant that nodes within the network environment 100A are communicatively coupled with each other such that they may send messages to each other using an addressing scheme, the messages being routed to their destination nodes based on the addressing. Further, a network environment may be seen as a set of nodes communicatively coupled so, that they may exchange messages with each other such that none of the communicatively coupled nodes needs to change its geographic location to convey these messages.

The master node and the worker nodes may comprise computing-capable units, such as desktop, laptop or tablet computers, smartphones, phablets or other suitable devices. The nodes need not be of a same type as it may be possible that, for example, the worker nodes are laptop and desktop computers and the master node is a tablet computer.

In case network environment 100A of master node <NUM> comprises a mesh/ad hoc network, it may be based, at least partly, on a near-field communication technology such as wireless local area network, WLAN, or Bluetooth, for example. As a further example, a simplified long term evolution, LTE, stack could be used in direct device-to-device mode.

Worker node <NUM> is not within network environment 100A of master node <NUM>. It has a network environment 100B of its own, which may be based on a near-field communication technology such as WLAN, Bluetooth or the simplified LTE stack, for example. As illustrated in <FIG>, network environments 100A, 100B are not communicatively coupled, meaning that messages released into one of these network environments will not be routed to the other based on addressing and routing tables, since there is no stable route connecting these network environments. Worker node <NUM> may be a relatively simple device with limited processing power. In some embodiments, worker node <NUM> is not a server.

Further, the system of <FIG> comprises broker node <NUM>/R. The broker node may be of a similar type as the master and/or worker nodes, as described above, for example. As a further example, the broker node may comprise a wireless-capable control unit of an automobile or an Internet of Things, IoT, or Industry <NUM>, node. A broker node may also be configured to perform as a worker node. The broker node may be, for the sake of description, in one of two locations. When it is in the network environment of master node <NUM>, it is denoted as broker node <NUM>, and when it is in the network environment of worker node <NUM>, it is denoted as broker node 120R. "L" refers to local and "R" to remote from the point of view of master node <NUM>. The movement of the broker node between these locations is denoted using curved arrows in <FIG>. The broker node may be enabled to move between positions <NUM> and 120R without being connected to network environments 100A or 100B. Further, in some embodiments, the broker node is enabled to visit in a specific sequence a plurality of short-range communication capable nodes, such as radio-frequency identification, RFID, tags, to collect from the short-range communication capable nodes a sequence of cryptographic information usable in accessing worker node <NUM>.

When in the network environment 100A of master node <NUM>, broker node <NUM> may receive a computation work package from master node <NUM>, the computation work package being addressed to worker node <NUM>. In the present text, a computation work package is referred to as a work package for brevity. By such addressing it may be meant addressing in a sense specific to messages of the distributed computation substrate. To enable this, the broker node may advertise an identity and/or capability of worker node <NUM> to master node <NUM>. The identity and/or capability information may comprise information relating to a messaging route from broker node <NUM> to worker node <NUM>, as will be described herein. For example, a number and identities of further broker nodes along a route to the worker node may be comprised in the information relating to the messaging route. Broker node <NUM> may have obtained this information from a previous association with worker node <NUM>, when the broker node was in position 120R. The broker node may store the computation work package in a memory internal to broker node <NUM>, or in a cloud storage of broker node <NUM> which the broker node may access also when outside the network environment 100A of master node <NUM>. Worker node <NUM> may, in general, be a mobile node or a fixed, non-mobile node. Where worker node <NUM> is mobile, it may share or agree route planning information with broker node <NUM>/R, to facilitate exchanges of work packages and results. Alternatively to disseminating the identity and/or capability information via the broker node, master node <NUM> may be configured with information characterizing worker node <NUM>, or more generally worker nodes outside network environment 100A of master node <NUM>. As a third option, worker node <NUM> may, in an initial phase, visit network environment 100A and directly communicate with master node <NUM> to join the distributed computation substrate. As a yet further variant, master node <NUM> may issue a request, via at least one broker node, to worker node <NUM> to visit network environment 100A, if possible.

Broker node <NUM>/R may interact with more than one worker node not in the network environment 100A of master node <NUM>. For example, broker node <NUM>/R may complete a workflow comprising multiple work packages using plural such worker nodes. An example is a case where broker node <NUM>/R instructs a first such worker node to switch on all street lights on a specific street. It may thereafter receive as a result an acknowledgement this has been accomplished, and/or information concerning lights that need replacing. Broker node <NUM>/R may subsequently interact with a second such worker node to issue to it a work package requesting this worker node to request a repair of the broken lights. Broker node <NUM>/R would finally report back to master node <NUM>, in position <NUM>, concerning all the actions undertaken.

One deployment for the system may be a broker node as a moving device, such as a drone carrying a communication device such as an RFID reader, Bluetooth or Bluetooth low-energy transceiver, for example, and a sequence of waypoints each having a tag. In the following an RFID tag is used as an example, with the understanding that in various embodiments the tags may be based on another short-range technology such as the afore-mentioned Bluetooth or Bluetooth-low energy. Waypoints would each provide a part of the signalled sequence of cryptographic information, denoted as D. The parts D together may form an answer to the puzzle, or be usable in deriving the answer. Further, waypoints may be configured to provide a timestamp T in embodiments where a time limit for completing a waypoint puzzle is enforced. Yet further, waypoints may be configured to provide keying material K. In case waypoints provide keying material, this keying material may be used in a subsequent waypoint, for example. In some embodiments, at least a part, and possibly all, of the waypoints are configured to not provide keying material, as that may be provided to the broker node as a pre-shared context relating to the waypoints. For example, a mission may deploy waypoint tags in such way that a resulting route and time limit is possible to reach with drone as a flying device, for example by having a large enough altitude variation. Location information may be in GPS coordinates. The waypoints may be worker nodes, depending on the embodiment. The waypoints may collectively indicate a route from network environment 100A to worker node <NUM>. The sequence of cryptographic information collected from the waypoints may enable the broker node to assign a work package to worker node <NUM>. A waypoint may inform the broker node of the next waypoint in the sequence. For example, a waypoint may provide to the broker node information of a geographical location of the next waypoint, and, in some embodiments, also radio information to facilitate successful communication between the broker node and the next waypoint. The radio information is useful where the waypoints are of a heterogeneous nature, for example.

In IoT embodiments, when communicating between IoT nodes assuming the roles of broker nodes and waypoints some authorization or security problems may arise. Therefore, in one embodiment a high-level logic of a puzzle manager is provided. The waypoints may comprise pre-shared secrets/keys to provide access rights, for example. In one example, once an execute transaction is issued by a master node, a proper pre-shared context may be selected for the requested transaction and the puzzle solution parts may be collected, that is, the broker node interacts with the waypoints in the correct sequence, until it is determined that all puzzle parts have been collected and it is time to create a puzzle solution and open new media channel in order to complete verification with a final waypoint, for example. If the verification is successful, then the requested action is performed and in any case, the status of the verification or the action may be returned back to the execute transaction caller. There may be two types of broker nodes, firstly, ones which navigate autonomously between the network environments of the master node and worker nodes, as illustrated in <FIG> and <FIG>, and secondly, broker nodes relying on waypoints, as in <FIG>.

A waypoint puzzle proceeds from an ingress waypoint to an egress waypoint. Ingress waypoint, N (<NUM> to many) waypoints and Egress waypoint may form a geographical topology that is traversed by broker node starting from the ingress waypoint and ending to the egress waypoint. The goal for the broker node is to perform securely certain actions guarded by the egress waypoint and the solution derived from the collected puzzle(s) is used to grant corresponding permissions. The topology is traversed via certain route, waypoint after waypoint, and from a waypoint perspective, there are <NUM> phases; <NUM>) pre-waypoint and <NUM>) waypoint, which will be described below. Each data Ld, where L is a unique identifier of a waypoint, provided by a waypoint includes puzzle information required for the egress waypoint verifying the puzzle solution. In other words, in case of eight waypoints, in order to pass the verification phase carried out by the egress waypoint, the puzzle solution is constructed from data vector Ld, where L=[<NUM>,.

Multiple puzzles, each with a specific route with the related waypoints, could be supported at the same time. The ingress waypoint could use round robin or some other scheme to select which route is provided for requests and each route may have a specific RFID tag sequence as the waypoints, each RFID tag having Ld + Lk +T, where Lk is keying material specific to that waypoint. These routes could use some shared waypoints. Also, considering that broker node may comprise a drone, then since drone IDs could be part of pre-shared contexts, then each route could be assigned to certain drones by having drone IDs included in its tag. In this case, a drone could receive a list of all tags to visit from the ingress waypoint and then it would have to process each tag to see with which routes its ID is associated. And if its ID is associated with more than one route, then it should select the route to be used according to local policies, such as round robin, for example. This multi-tag receiving could be done also in other waypoints after the ingress waypoint, but it also could be that only the ingress waypoint provides route choices after which the drone makes the selection there, subsequently following the selected route. A route is illustrated in <FIG>.

A puzzle solution may be created in one embodiment of a use case where a drone has a pre-shared context/secret, with waypoints WP acting as the worker nodes. A route comprises the ingress waypoint, WP2 to WP8 and the egress waypoint, for example. A waypoint comprises location coordinates, like GPS coordinates, for example. Further, for communication, a radio such as RFID may be used. It is the egress waypoint that solves the RFID waypoint puzzle in this example. In this case, the invention is vulnerable, if a rogue drone becomes aware of the pre-shared information of the ingress waypoint, because after that it could solve the puzzle. This could happen due to the fact that anyone can listen to encrypted RFIDs from WPs, but only trusted parties could decrypt and interpret them. To prevent this from happening, there may be more than one pre-shared item of information in each waypoint puzzle.

A further example is a case when the drone has two pre-shared secrets: one with the ingress waypoint and another one with WP-<NUM>, for example. In this case, the rogue drone that knows the pre-shared context/secret of the ingress waypoint cannot solve the whole puzzle, because its journey would end at WP-<NUM>, because it cannot figure out a next WP, which would be WP-<NUM> - For that it would need also pre-shared info of WP-<NUM>.

In a generalization of how a broker node solves a waypoint puzzle is possible. If a timed event feature is used, the ingress waypoint provides a timestamp that the master node may include in the puzzle solution at the egress waypoint. An assumption is herein made, that the ingress and egress waypoints have pre-shared context information that they may use to encrypt/decrypt the timestamp, so that the broker node cannot change it and thus try to fool the egress waypoint to pass timed event verification. A verification procedure at the egress waypoint may comprise checking both the timestamp and the solution. If a timestamp is too old or is altered, the verification fails. After that also the puzzle solution may need to be matched. If the puzzle solution is successful, then broker node is allowed to proceed to task(s) that the waypoint puzzle is built to guard.

Subsequently, when the broker node is in position 120R, it forwards the computation work package to worker node <NUM>, which is then in a position to begin work on the work package. Broker node <NUM>/R may leave the network environment 100B of worker node <NUM> while the worker node works on the work package, and collect the result of the computation work package when broker node <NUM>/R eventually returns to network environment 100B. Once the broker node has the result, it may provide it to master node <NUM> when it once more finds itself in network environment 100A of master node <NUM>. Of note, the result of the computation work package may be conveyed to master node <NUM> by nodes other than the specific broker node <NUM>/R which provided the computation work package to worker node <NUM>. In detail, there may be more than one broker node. There may, further, be separate ways for the result to be provided, as an example a user of worker node <NUM> may periodically send memory sticks with results of computation work packages to a user of master node <NUM> by post or courier.

In general, the computation work package and the result may have a same transaction ID, enabling the master node to know, which work package the result completes. Further, a broker node may be configured to maintain source-destination-transaction bindings, such that a request-response pair may be seen as four separate phases: master -> broker, broker -> worker, worker -> broker and broker -> master. Alternatively, broker nodes may be configured to forward work packages and results in a stateless manner, based on routing information in the work packages and results.

Routing information may comprise, for example, a network address and/or geographic location of a worker node. Routing information may further, or alternatively, comprise at least one network address of a node capable of forwarding a work package toward the worker node the work package is addressed to. In some embodiments, an overall end-to-end route from master node <NUM> to worker node <NUM> comprises a waypoint-navigated part and an autonomously navigated part, and routing information comprises information usable in proceeding to the ingress waypoint of the waypoint sequence. Information usable in proceeding to the ingress waypoint of the waypoint sequence may comprise at least one of: a location of the ingress waypoint, radio capabilities of the ingress waypoint, at least one protocol used by the ingress waypoint, for example. This information may thus not only assist in proceeding to the ingress waypoint, but also in communicating with the ingress waypoint.

The computation work package comprises instructions for processing in a worker node, such as worker node <NUM>. The work package may comprise data to be processed, or, alternatively or additionally, information enabling a worker node to obtain the data. Master node <NUM> may be configured to provide computation work packages also to worker nodes <NUM> and <NUM>, as these are within the network environment 100A the master node <NUM> can easily send these work packages to these worker nodes. In some embodiments, master node <NUM> decides based on the capability of a worker node the work package is intended for whether to include the data, such that for worker nodes capable of accessing the data over a network, master node <NUM> does not include the data but for worker nodes not capable of accessing the data over a network, master node <NUM> includes the data in the work package. In general, a work package may comprise one or more tasks for a worker node to perform. A work package may comprise routing information to assist in delivering it to the correct worker node.

A computation work package of the distributed computation substrate comprising worker nodes <NUM>, <NUM> and <NUM> may be directed to an individual aspect of a larger parallelized computing process. For example, simulating protein folding, processing astrophysical or particle-physics experimental data and numerical searches for pharmaceutical compounds are processing-intensive computational tasks which lend themselves to being performed in parallel processes with relative ease.

As illustrated in <FIG>, when broker node <NUM>/R moves in a cyclical and predictable manner between network environments 100A and 100B, the master node <NUM> is enabled to include worker node <NUM> in the distributed computation substrate it manages. Computation work packages and results thereof may be communicated between worker node <NUM> and master node <NUM> via broker node <NUM>/R. To an extent, broker node <NUM>/R may appear as worker node <NUM> toward master node <NUM>, and broker node <NUM>/R may appear as master node <NUM> toward worker node <NUM>.

A node may become a broker node in a dynamical process, whereby the node keeps a record of worker nodes it encounters as it moves around, for example as it is carried around by a user as he moves about his daily routines. A node may determine, based on its records, that it tends to encounter specific worker nodes more or less regularly, and as a response to this determination, offer the capabilities of these worker nodes to master node <NUM>. In this aspect, worker node <NUM> need not be immobile, as it is sufficient that it encounters the broker node repeatedly. The worker nodes may indicate, for example as broadcasted information, their identity and/or capability and willingness to participate in a distributed computation substrate, for example. In case master node <NUM> does not trust a specific worker node outside the master node's network environment 100A, the master node may provide the data to be computed on as part of the computation work package in encrypted form, the work package comprising instructions for the worker node to perform processing on this encrypted data using homomorphic encryption, such that the worker node may process the data without learning the content of the data.

A dynamic broker node role may arise naturally from the daily habits of users, since people often have regular routes they take, for example from home to work, work to gym, and gym to home. In general, the master node may be configured to perform asynchronously, not waiting for a result of a computation work package before sending out further computation work packages to other worker nodes. This is especially useful with worker nodes connected to the master node via broker nodes, as delays in communication may be long and unpredictable in length.

<FIG> illustrates an example system in accordance with at least some embodiments of the present invention. In detail, the system of <FIG> has two broker nodes, <NUM>/R and <NUM>/R. Like numbering denotes like structure as in <FIG>. Broker node <NUM>/R may be configured essentially as in the system of <FIG>, except that in the system of <FIG>, this broker node is configured to interact not only with master node <NUM> and worker nodes, but also with other broker nodes, such as broker node <NUM>/R. Broker node <NUM>/R is mobile, like broker node <NUM>/R, and has a "local" position <NUM> and a "remote" position 122R. In position 122R, this broker node is within the network environment of worker node <NUM>.

In the embodiment of <FIG>, broker node <NUM>/R receives identity and/or capability information of worker node <NUM> not directly from worker node <NUM>, but from worker node <NUM> via broker node <NUM>/R, as broker node moves from position 122R, where it receives this information from worker node <NUM> to position <NUM>, where it can provide this information to broker node <NUM>/R. Broker node <NUM>/R provides this identity and/or capability information to master node <NUM>, and receives a computation work package for worker node <NUM> from master node <NUM> when in position <NUM>. When in position 120R, broker node <NUM>/R forwards the work package to broker node <NUM>/R which is them position <NUM>. Thus, in general, a broker node may communicate a work package between itself and either the worker node the work package is addressed to, or another broker node. This amounts to requesting that broker node <NUM>/R forward the computation work package onward toward worker node <NUM>. Communication interface <NUM> enables communication between the broker nodes. Communication interface <NUM> may comprise a Bluetooth, Wibree, WLAN interface or a simplified LTE stack in direct device to device mode, for example. A work package may comprise routing information to assist forwarding to toward, and ultimately delivering it to, worker node <NUM>. The master node may compile this routing information based on the identity and/or capability information it received, for example. A routing protocol may be used in relaying work packages and/or results in case paths are not static. Where broker nodes are stateful, the route from master node to worker node may be the same, but in reverse order, as the route from worker node to master node. In some embodiments, a route from master node to worker node is based on routing information in the work package, but the reverse route is determined dynamically based on a routing protocol. In some embodiments routes in both directions are based on routing information, whereas in some embodiments, on the other hand, both directions are based on a routing protocol and in yet further embodiments, the route from master node to worker node is based on a routing protocol and the reverse route on routing information. In some embodiments, routing protocols and routing information may be freely used between master node(s) and worker node(s).

When in positions 120R and <NUM>, the broker nodes may both be outside the network environments of both the master node <NUM> and the worker node <NUM>, as illustrated in <FIG>.

Broker node <NUM>/R may be configured to add an indication to the identity and/or capability information of worker node <NUM>, indicating to master node <NUM> that broker node <NUM>/R has not directly been in communication with this worker node. Master node <NUM> may take this indication into account when compiling computation work packages for worker nodes, since a worker node only reachable over two broker nodes may be less reliably reachable than a worker node reachable over a single broker node. In principle, there may be more than two broker nodes in a chain of broker nodes. In such embodiments, each broker node may be configured to add the indication to the identity and/or capability information, such that the master node is thereby enabled to determine the length of the broker node chain needed to reach that specific worker node.

In some embodiments, the longer the chain, the less reliable is the reachability. Master node <NUM> may be configured to assign less urgent computation work packages to worker nodes behind longer chains of broker nodes. In general, a master node may be configured to determine, from identity and/or capability information relating to a worker node, a length of a broker node chain connecting the master node to the worker node, and to assign more urgent computation work packages to worker nodes with shorter broker node chains, and to assign less urgent computation work packages to worker nodes with longer broker node chains. For example, a protein-folding simulation work package may be seen as less urgent, while processing a radar signal may be seen as more urgent.

<FIG> illustrates an example apparatus capable of supporting at least some embodiments of the present invention. Illustrated is device <NUM>, which may comprise, for example, a master node or broker node of <FIG> or <FIG>. Comprised in device <NUM> is processor <NUM>, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor <NUM> may comprise, in general, a control device. Processor <NUM> may comprise more than one processor. Processor <NUM> may be a control device. A processing core may comprise, for example, a Cortex-A8 processing core manufactured by ARM Holdings or a Zen processing core designed by Advanced Micro Devices, AMD Corporation. Processor <NUM> may comprise at least one AMD Ryzen and/or Intel Core processor. Processor <NUM> may comprise at least one application-specific integrated circuit, ASIC. Processor <NUM> may comprise at least one field-programmable gate array, FPGA. Processor <NUM> may be means for performing method steps in device <NUM>. For example, processor <NUM> may be means for receiving, forwarding and providing. Processor <NUM> may be configured, at least in part by computer instructions, to perform actions.

A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with embodiments described herein. As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

Device <NUM> may comprise a transmitter <NUM>. Device <NUM> may comprise a receiver <NUM>. Transmitter <NUM> and receiver <NUM> may be configured to transmit and receive, respectively, information in accordance with at least one cellular or non-cellular standard. Transmitter <NUM> may comprise more than one transmitter. Receiver <NUM> may comprise more than one receiver. Transmitter <NUM> and/or receiver <NUM> may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, <NUM>, long term evolution, LTE, IS-<NUM>, wireless local area network, WLAN, Ethernet and/or worldwide interoperability for microwave access, WiMAX, standards, for example.

Device <NUM> may comprise user interface, UI, <NUM>. UI <NUM> may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device <NUM> to vibrate, a speaker and a microphone. A user may be able to operate device <NUM> via UI <NUM>, for example to configure distributed processing tasks.

Device <NUM> may comprise further devices not illustrated in <FIG>. For example, where device <NUM> comprises a smartphone, it may comprise at least one digital camera. Some devices <NUM> may comprise a back-facing camera and a front-facing camera, wherein the back-facing camera may be intended for digital photography and the front-facing camera for video telephony. Device <NUM> may comprise a fingerprint sensor arranged to authenticate, at least in part, a user of device <NUM>. In some embodiments, device <NUM> lacks at least one device described above. For example, some devices <NUM> may lack a NFC transceiver <NUM>.

Processor <NUM>, memory <NUM>, transmitter <NUM>, receiver <NUM>, NFC transceiver <NUM> and/or UI <NUM> may be interconnected by electrical leads internal to device <NUM> in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device <NUM>, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

<FIG> illustrates signalling in accordance with at least some embodiments of the present invention. On the vertical axes are disposed, from the left to the right, master node <NUM>, broker node <NUM>/R and worker node <NUM> of <FIG>. Time advances from the top toward the bottom.

In phase <NUM>, broker node <NUM>/R receives identity and/or capability information of worker node <NUM>, while in communication with worker node <NUM>, that is, in the "R" position of <FIG>. In phase <NUM>, broker node <NUM>/R moves to the "L" position in <FIG>, and subsequently provides, in phase <NUM>, the identity and/or capability information to master node <NUM> which thus becomes aware of the capabilities of worker <NUM>, which it may invoke in the distributed computation substrate, such as grid, that master node <NUM> coordinates.

In phase <NUM>, the master node is triggered to perform computational tasks using its distributed computation substrate. In response, master node <NUM> compiles computation work packages and distributes them to worker nodes in the distributed computation substrate. One of the work packages is addressed to worker <NUM>, and this package is provided to broker node <NUM>/R in phase <NUM>. In response, broker node <NUM>/R stores the work package and, once it has moved, phase <NUM>, to the "R" position of <FIG>, forwards, phase <NUM>, the work package to worker node <NUM>.

Worker node <NUM> processes the work package to obtain a result, phase <NUM>, and worker node <NUM> provides the result to broker node <NUM>/R in phase <NUM>. After broker node <NUM>/R has moved back to the "L" position of <FIG>, phase <NUM>, broker node <NUM>/R provides the result to master node <NUM>, phase <NUM>. Thus master node <NUM> has, overall, successfully had the work package processed by the remote worker node <NUM>, by using broker node <NUM>/R to relay the work package and result. Broker node <NUM>/R may move between the "L" and "R" positions of <FIG> several times during the time worker node <NUM> spends processing the work package, and likewise the broker node may leave position "L" and return there at least once between phases <NUM> and <NUM>.

Worker node <NUM> may provide results of more than one work package at the same time, when the broker node is within the network environment of worker node <NUM>.

<FIG> is a flow graph of a method in accordance with at least some embodiments of the present invention. The phases of the illustrated method may be performed in broker node <NUM>/R, or in a control device configured to control the functioning thereof, when installed therein.

Phase <NUM> comprises receiving, by an apparatus, when within a network environment of a master node of a distributed computation substrate, a computation work package addressed to a worker node. Phase <NUM> comprises determining that the apparatus has moved to a network environment of the worker node, wherein the network environment of the master node and the network environment of the worker node are not communicatively coupled. Not being communicatively coupled may comprise not being communicatively coupled with each other. Phase <NUM> comprises communicating the computation work package between the apparatus and the worker node or a broker node. This may comprise providing the work package to the worker node or to a broker node for forwarding onward to the worker node.

<FIG> is a flow graph of a method in accordance with at least some embodiments of the present invention. The phases of the illustrated method may be performed in master node <NUM>, or in a control device configured to control the functioning thereof, when installed therein.

Phase <NUM> comprises providing, by an apparatus, to a broker node of a distributed computation substrate, a computation work package addressed to a worker node of the distributed computation substrate, the worker node not being within a network environment communicatively coupled with a network environment of the apparatus. Phase <NUM> comprises receiving, from the broker node, a result of the computation work package.

It is to be understood that the use of "a" or "an", that is, a singular form, throughout this document does not exclude a plurality.

At least some embodiments of the present invention find industrial application in obtaining enhances use rates of geographically distributed computation nodes.

Claim 1:
An apparatus (<NUM>) comprising at least one processing core (<NUM>), at least one memory (<NUM>) including computer program code, the at least one memory (<NUM>) and the computer program code being configured to, with the at least one processing core (<NUM>), cause the apparatus (<NUM>) at least to:
- receive (<NUM>), when within a radio network environment of a master node of a distributed computation substrate, a computation work package addressed to a worker node, and
- forward (<NUM>) the computation work package from the apparatus to the worker node,
- characterized in that the at least one memory (<NUM>) and the computer program code are configured to, with the at least one processing core (<NUM>), further cause the apparatus (<NUM>) to:
- determine (<NUM>), after receiving the computation work package, that the apparatus (<NUM>) has geographically moved to a radio network environment of the worker node, wherein the radio network environment of the master node and the radio network environment of the worker node are geographically separate and not directly communicatively coupled with each other, and to perform the forwarding (<NUM>) to the worker node in the radio network environment of the worker node, and
- receive a result of the computation work package from the worker node and forward the result to the master node when the apparatus is in the radio network environment of the master node.