Patent Description:
Today a user normally has multiple personal digital devices. For example, a user at least has a smart phone, one or multiple wearables (e.g. smart watch, fitness armbands and wireless earphones), one or multiple home appliances such as air-conditioner, lighting system, security web-cameras and so on. In addition to digital products, a user also has many applications (Apps) installed on devices, wherein some of Apps are paid subscription services.

A clear trend is that those devices are equipped with networking capability, in which wireless fidelity (WiFi) and Bluetooth interfaces are common. In the near future, interfaces to cellular networks will also be common on devices. For example, many smart watches on the market already are equipped with cellular functionality such as Apple Watch. Future mobile networks are expected to provide pervasive wireless coverage and high throughput/low latency connections for Internet-of-things (IoT). It is predicted that there will be <NUM> billion of IoT devices connected to the network by <NUM>.

Service providers play different roles to provide various services to connected devices. For example, a mobile operator provides mobile communication services to mobile users (e.g. wireless coverage with network connectivity); vendors provide backend services for product maintenance and added value services; over the tops (OTTs) build applications (Apps) to enrich, diversify and amplify the utilizations of devices.

On the one hand, this shows a centralized control paradigm by the service providers. In specific, service catalogs are totally defined by a service provider; the feature on a device has to be provided by its vendor; and a specific functionality of an App has to be enabled by the OTT.

On the other hand, as an owner of devices and Apps, there is a very limited space where the services or features can be customized. It is even impossible for a user to associate two devices to temporally form a logically new device, especially when they are products of different vendors. In general, the current service paradigm can be seen as a provider-centric paradigm.

A provider-centric paradigm shows the following limitations: <NUM>) a user will have to manage different accounts for different services; <NUM>) seamless interoperability between devices of different vendors would be difficult. For example, a user has to manually pair a loudspeaker with a mobile phone via Bluetooth, which is usually cumbersome; <NUM>) a user loses control over data once the data is transmitted to the server side. For example, personal data (e.g. photos, traces, browsing history), profiles and usage statistics are reportedly abused by some service providers (e.g. the privacy branch scandal of Facebook); and <NUM>) a user cannot customize, combine, and/or compose with available services of its own.

However, there are many scenarios where a user needs more flexibility and self-control over the services. The reason is that application scenarios cannot be pre-defined anymore. For instance, a user may want to dynamically decide if a HiFi loudspeaker should connect to its TV or its mobile phone; a user may also want to project a video through a projector nearby; a user may want to copy some files from a MacBook to a Windows PC without using a third party App; a user may even want to share private data (e.g. photos) in an encrypted way but combine to use multiple cloud storage providers (e.g. split between Google Cloud and Dropbox). All these scenarios will become increasingly popular with personalization. But there is no solution for providing self-control of service or device composition currently.

<CIT> relates to creating and updating a user profile related to multiple devices, and synchronizing applications' sessions for the user on different devices.

In view of the above-mentioned limitations, embodiments of the present invention aim to introduce a solution for composing a synthesized service in wireless network. In particular, an objective is to provide new types of services that may be customized by one or more user's devices. A general goal aims to allow a user to have fully control on how its devices,.

Apps and subscriptions therein should work cooperatively.

In particular, it is desired to provide a solution for managing resources to form a temporally collaborative group with a set of devices, Apps and/or subscriptions, so that a logically new device may be created by the wish of the user.

The objective is achieved by embodiments as provided in the enclosed independent claims.

Advantageous implementations of the embodiments are further defined in the dependent claims.

The above described aspects and implementation forms of the embodiments of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which.

Illustrative embodiments of method, device, and program product for efficient packet transmission in a communication system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples.

The previously described scenarios, in which a user needs more flexibility and self-control over the services, are considered as a "user-centric" paradigm. Note that a user here is not just limited to a natural person who owns one or several devices or Apps. A user eventually represented or delegated by a device generalizes as a logical entity which would like to form temporal collaborations, which is planned, controlled and operated by the device. The device may under control of the user who owns some resources e.g. devices, equipment and software. In specific, through a device, a user will have to be able to define synthesized services based on existing resources e.g. devices, Apps and subscriptions.

In general, existing solutions provide very limited space for service composition, although they target to enrich their services, e.g. enabling more features on their devices and/or apps. We classify them in the categories as follows.

The first class of existing solutions is called closed ecosystem. Within the ecosystem, the vendor develops various features for its products. Many of them enable cross-device collaborations and improve productivity.

For example, with Apple's Macbook and iPhone/iPad, the so-called universal clipboard service allows a user to copy at one device and seamlessly paste on another device; another example is Huawei's Multi-screen Collaborations such as phone-to-laptop and laptop-to-phone synchronization; Huawei's Vision TV, which integrates IoT control, information-sharing center, smartphone mirroring and so on; This in general aims to provide a method for information sharing among multiple devices either through a communication network or a local hub device. In addition, Samsung provides its SmartThings Hub® that supports adding IoT devices to the hub, and managing them through an App. Every vendor on the market tries to build an ecosystem with its own products.

Usually, every vendor tries to specialize its own products in order to distinguish products of its opponents. This aims to compete the market share.

The second class of existing solutions is called third party App. Many third party Apps are developed in order to overcome the barrier between the devices from different vendors. A third party App acts as an intermediate gateway where the information flow can be bridged between two different ecosystems. Examples include many existing cloud storage services (e.g. Google Drive, Dropbox, Microsoft Azure and so on), 1Clipboard based on Google Drive realizes the same functionality as Apple's Universal Clipboard, 1Password as a password manager delegating the authentication to different OTTs. In a different way, software companies are also trying to build their own ecosystem that dominates the usage on devices.

The third class of existing solutions is from mobile network operators. Recently, operators start to play a more important role not only at traditional mobile services (e.g. calling and internet surfing with a data plan, but also at other service enabling such as proximity services (ProSe). A ProSe function gives a possibility that neighboring devices may communicate directly with each other without going through the infrastructure. An operator acts as a moderator for service discovery and radio resource scheduling, and coordinated devices, no matter if they are from the same vendor, manufacturers or software companies. For example, in V2X communication, cooperative awareness message (CAM) and Decentralized Environmental Notification Message (DENM) are typical scenarios where ProSe function helps.

However, the main disadvantages of existing solutions are summarized as follows.

Firstly, a boundary exists between vendors, software developers (companies) and operators. This boundary blocks many possible collaborations across products, Apps and subscribers. For instance, a Samsung smartphone cannot copy-paste to an Apple's Macbook, unless an App does this job. Sometimes, such a boundary is deliberately maintained in order to prevent competitors.

Secondly, neither a closed ecosystem nor an App can cover all use cases, which is an endless wish list. Requirements from users are diverse and unpredictable. A service provider focuses more on those popular use cases. Though the ProSe function provided by operators is neutral to the brands, it is only for service discovery between proximity subscribers. Thus, ProSe function does not really enable service composition.

The most critical disadvantage is that services provided with existing solutions are still under the control of respective service providers. What kinds of services and/or how the services that can be used are fully defined by the providers. With considering the first two deficiencies above, a user has limited space to customize with its existing resource to compose individually new services for itself.

In general, there is a missing part to realize a user-centric service paradigm, where a user yields an opportunity to compose self-defined services based on its available resources.

Firstly, the terms that will be used in this disclosure are defined as following:.

<FIG> shows a method <NUM> according to an embodiment of the invention, particularly for composing a service in wireless network. In a particular embodiment of the invention, the method <NUM> is performed by an SCF <NUM>. The method <NUM> comprises: a step <NUM> of receiving, by the SCF <NUM>, a request from a first device <NUM>, wherein the request is used to prescribe synthesized functionalities provided by one or more second devices <NUM> to form a first logical device; and a step <NUM> of providing, by the SCF <NUM>, configuration information to the one or more second devices <NUM> based on the request, wherein the configuration information indicates a set of actions and/or parameters to form the first logical device.

In order to realize an SC, first of all, a user should have a unified way to manage devices, which have been authorized for management. According to embodiments of this invention, the first device may be a device accessed by the user, and the second devices may be the devices, which have been authorized for management, including the devices that may belong to the device owner or may belong to another device owner. In addition, a user may able to plan an SC through the first device. The SC describes how functionalities of a first logical device shall be synthesized. According to embodiments of the invention, the first device sends the request to the SCF, to prescribe the synthesized functionalities provided by one or more second devices. Moreover, a composed service may be deployed and controlled in run time in order to guarantee a service quality and align with any incurred policy.

The technical problem(s) that have to be solved may as follows: <NUM>) how to create and maintain a profile list of all available devices in a unified way; <NUM>) how to formulate an SC based on the maintained device profile, for example, the connectivity pattern, an execution logic and service policy for a set of devices; and <NUM>) how a formulated SC can be deployed onto the respective device.

Embodiments of this invention propose a user-controlled function acting as a service hub for the devices, called service-composition network function (SC-NF) or simply service composition function (SCF).

SC-NF or SCF serves the following main purposes:.

A general architecture with the proposed SCF / SC-NF <NUM>, according to an embodiment of the invention, is depicted in <FIG>.

A device Dev U <NUM> which has the authority to manage the devices <NUM> (i.e. Dev1, Dev2 to Dev K and Dev U), is shown in <FIG>. The devices <NUM> may be controlled by the owner of the device U. The devices <NUM> may be owned by the user of device Dev U <NUM> or by other users. A user may use the Dev U <NUM> to interact with SC-NF <NUM> where such devices may or may not participate an SC. The general procedure for an SC is described as follows.

Firstly, a device may be registered to SC-NF <NUM>, wherein a profile list will be created at SC-NF <NUM> and specifications, configurations, profiles and credentials are maintained there.

Secondly, an SC request is sent to SC-NF <NUM> from the Dev U <NUM>. In the request, a set of devices are specified and how involved devices should collaborate to each other is prescribed. These tasks will be done with signaling between the SC-NF <NUM> and the Dev U <NUM> over an interface, for instance, named as Intf_SC-NF2Dev.

Thirdly, the SC request will be processed by the SC-NF <NUM>. After that, SC-NF <NUM> will decompose the SC into detailed configurations for every device <NUM> with logical relationships, interface parameters, collaboration policies and so on.

The detailed configurations may be deployed onto each device <NUM> to realize the SC. After the deployment, SC-NF <NUM> monitors the execution status and coordinate the involved resource to fulfill service requirements if applicable. These tasks may be done with the signaling between the SC-NF <NUM> and every device <NUM> over an interface, e.g. the Intf_SC-NF2Dev.

The SC-NF <NUM> has multiple embodiment options, which are briefly discussed as follows.

The first embodiment is that the SC-NF <NUM> may be implemented in an operator's network. For example, the operator may provision resource to run an SC-NF <NUM> instance in the operator's network. The Dev U <NUM> interacts with the SC-NF instance over wireless connectivity provided by a mobile network. The architecture according to this embodiment of the invention, is depicted in <FIG>.

The second embodiment option is that the SC-NF <NUM> may be implemented as an OTT service as shown in <FIG>. For example, a cloud data center provider may provision resource to run an SC-NF <NUM> as a tenant service. The cloud data center guarantees provisioned execution resource to the SC-NF <NUM>. In addition, a cloud service provider could also provide SC-NF instantiation. The device <NUM> may access the SC-NF <NUM> through any possible network connectivity such as mobile network / WiFi connections.

Another possibility of the architecture is decentralization (not shown in figure here). The decentralized architecture may be the combined architecture of <FIG> and <FIG>. For instance, a part of the SC-NF <NUM> functions situate in OTT (e.g. part <NUM>), and a part of the SC-NF <NUM> situate in operator's network (e.g. part <NUM>). The part <NUM> and part <NUM> coordinate with each other to provide functionalities of a logic SC-NF entity.

The third embodiment is that an SC-NF <NUM> may be implemented on a device <NUM> (e.g. Dev2) as shown in <FIG>. For example, it may be just a program on a smartphone considering that the smartphone may be capable enough to provide resource for SC-NF <NUM>. In this case, the Dev U <NUM> manages all resources and processes SC request.

Another example is that the main hub device or the SC-NF <NUM> may situate in a local network, e.g. router or WiFi box at home. The Dev U <NUM> may manage and control some/all devices at home to compose a service using local wireless network.

In another possible implementation, the Dev U <NUM> may proactively collect or have the information of other devices around, and start to design SC with the discovered resource. For example, the Dev U <NUM> may send broadcast or unicast message to each of the devices nearby to compose a service. All these variants will be further discussed in following embodiment sections.

SC-NF or SCF in 3GPP network: The first embodiment is that the SC is realized by utilizing a mobile network system. In this case, devices interact with SC-NF <NUM>, which is a special user plane network function (UP-NF) long-lived running in an operator's network domain. The detailed procedure is illustrated in <FIG>.

The device <NUM> accessed by a user may send a request for an SC-NF instance creation. The request may be an activation switch turned on the device or it may also be a request sent manually from the device <NUM> e.g. making a call through the operator's network.

A device <NUM> is registered at SC-NF <NUM>. In registration, it comprises registration information, particularly description, of the device <NUM>. Attributes of a device description may include one or more of the attributes in Table <NUM> as example, or may not be limited to the fields in Table <NUM>.

A registered device <NUM> may be updated by sending a new registration request with new descriptions or by some specific reconfiguration.

According to embodiment of the invention, there are generally two ways to register a device. The first way may be that a device registers for another device at SC-NF <NUM>. For example, Dev U registers for Dev A. The second way may be that a device registers itself at SC-NF <NUM>. For example, the Dev U <NUM> registers itself, which refers to a case that Dev U <NUM> and Dev A <NUM> are the same, i.e., Dev U <NUM> is Dev A <NUM>.

The SC-NF <NUM> receives the registration request and there are two possibilities to verify the status (availability) of the device <NUM>:.

However, there is an exception where a device is an offline device. For example, a device <NUM> may only have Bluetooth, infrared and/or WiFi interface(s), so it cannot be reached by or connect to SC-NF <NUM>. From the SC-NF's point of view, the device <NUM> is an offline resource. In this case, the SC-NF <NUM> ignores its availability check while just stores the device description. However, an offline device should also be able to participate a future SC, while the device <NUM> will have to make sure the availability of a non-cellular device.

The SC-NF <NUM> sends a registration response to notify the registration result. The registration response may be sent to the SC-NF client or the registered device <NUM>, depending on the method how the device <NUM> was registered. A successful registration may be that a device eventually passes the verification check. A failed registration may be that the SC-NF <NUM> finds the attributes of the verified device not matching with the registration requests or the SC-NF <NUM> fails to communicate with the device.

An SC request is defined and sent to SC-NF <NUM>. The service composition request defines how a set of registered resources may be utilized for a given objective. In specific, an SC may include at least one of the parameters in.

An SC request may be generated by the device <NUM>. The device <NUM> may provide a friendly interface to the user who may easily design an SC, e.g. having a graphic user interface and/or a command line terminal. With synchronized view of all available devices, an initial feasibility can be done for a proposed SC. Note that an SC request may also include SC-NF <NUM> as part of the workflow.

The SC request is processed by SC-NF <NUM>. In specific, SC-NF <NUM> may check the requirements of the SC request and match them with the current device availability status. This may include the checklist in Table <NUM>.

If the checklist is fulfilled, SC-NF <NUM> prescribes a workflow with configurations for individual device. Otherwise, SC-NF <NUM> will reply to the device <NUM> that the SC is infeasible.

The configuration is sent to every involved device with specified configuration parameters. The configuration may at least contain the parameters in Table <NUM>.

Configurations will be deployed by all involved devices and after that the SC starts to work. A summary of the deployment is collected by the SC-NF <NUM> and sent back to the device <NUM> as a deployment result.

In run-time, according to the monitoring status, the devices <NUM> may send status update to SC-NF <NUM>. Sometimes, the device <NUM> may find the service quality cannot be fulfilled, and the devices <NUM> may send proactively status update to the SC-NF <NUM>.

While in some other scenarios, the SC-NF <NUM> may also update the quality requirements to the devices <NUM>, for example, the radio environment is changed. If the adjustment cannot fulfill the requirement of the SC, SC-NF <NUM> stops the SC.

SC-NF <NUM> sends a response to the device <NUM> about the deployment status. Note that from Step <NUM> to Step <NUM>, it can be a loop until a termination condition is triggered. A termination condition may be specified as in the SC request, or as a new request from a device <NUM>.

To terminate an SC, SC-NF <NUM> sends a termination notification to every involved device <NUM>.

SC-NF <NUM> sends a service summary to the requesting device <NUM>.

SC-NF or SCF in clouds: A similar embodiment is that an SC-NF is deployed in a cloud environment. In this embodiment, the SC-NF instance runs in cloud data centers ranging from big data centers at a centralized location to micro data centers at edge of the network.

The role of a cloud provider may be the resource provider accommodating the SC-NF instance, or the provider of SC-NF logic itself. In a first case, the cloud provider is agnostic to the SC-NF instance. In a second case, the cloud provider is aware of the functionality of SC-NF instance and may provide additional assistances to the SC-NF instance. In both cases, the sovereignty of the SC-NF instance belongs to its owner who deploys it in a cloud service provider.

The procedure of how service composition is realized with SC-NF deployed in clouds is depicted in <FIG>. In particular, the procedure comprises the following steps:.

It can be seen that, the SC-NF <NUM> may be implemented at different layers on the main hub device <NUM>. Firstly, this may be an App developed directly by a vendor who supports service composition for its own products (i.e. devices/Apps). This App may also support products from other companies if a standardized interface/protocol is used. Secondly, it may be a third party App, where different software companies may provide similar kind of Apps but featured with special designs that differentiate themselves to the other. Thirdly, this may be a kernel level functionality in the operation system (OS), which requires main OS providers to support service composition functionalities.

<FIG> shows a method <NUM> according to an embodiment of the invention, particularly for service composition in wireless network. In a particular embodiment of the invention, the method <NUM> may be performed by a first device <NUM>. The method <NUM> comprises: a step <NUM> of determining a first logical device to be formed; and a step <NUM> of sending a request to an SCF <NUM>, for synthesizing functionalities for the first logical device, wherein the request is used to request the SCF <NUM> to prescribe synthesized functionalities provided by one or more second devices <NUM> to form the first logical device, and the request comprises configurations for the one or more second devices <NUM>.

<FIG> shows a network entity <NUM> adapted for composing a service in wireless network according to an embodiment of the invention. The network entity <NUM> may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the network entity <NUM> described herein. The processing circuitry may comprise hardware and/or software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The network entity <NUM> may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the network entity <NUM> to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the network entity <NUM> to perform, conduct or initiate the operations or methods described herein.

The network entity <NUM> may further comprise a communication interface, e.g. transceiver which is used to receive/transmit message from/to other devices, e.g. device <NUM>, or <NUM> etc..

In particular, the communication interface of the network entity <NUM> may be configured to receive a request <NUM> from a first device <NUM>, wherein the request <NUM> may be used to prescribe synthesized functionalities provided by one or more second devices <NUM> to form a first logical device. Further, the processor of the network entity <NUM> may be configured to provide configuration information <NUM> to the one or more second devices <NUM> based on the request <NUM>, wherein the configuration information <NUM> indicates a set of actions and/or parameters to form the first logical device. According to embodiments of this invention, an SCF may be implemented on the network entity <NUM>.

The network entity <NUM> may be able to perform or executed the procedures described in previous embodiments to act as an SCF <NUM> using for example the processor. It should be noted that, the network entity <NUM> according to embodiments of this invention, may be a user-controlled entity. It is different from a conventional network entity, which may be controlled by a network operator.

<FIG> shows a user entity <NUM> adapted for service composition in wireless network according to an embodiment of the invention. The user entity <NUM> may be the devices <NUM> and/or <NUM> in the previous embodiments. The user entity <NUM> may be configured to determine a first logical device to be formed. Further, the user entity <NUM> may be configured to send a request <NUM> to an SCF <NUM>, for synthesizing functionalities for the first logical device. In particular, the request <NUM> may be used to request the SCF <NUM> to prescribe synthesized functionalities provided by one or more second devices <NUM> to form the first logical device, and the request <NUM> comprises configurations for the one or more second devices <NUM>. In a specific embodiment, the network entity <NUM> shown in <FIG> may be the network entity <NUM> shown in <FIG>. According to embodiments of this invention, the user entity <NUM> may be a user device controlled and managed by a user.

To summarize, this disclosure proposes a solution for service composition with devices. In particular, the disclosure involves three parts: <NUM>) a set of devices, which can be networked and/or offline and managed by a user/device, <NUM>) a newly proposed NF (i.e., SC-NF that provides the functionality of service composition) and <NUM>) interfaces between the device (user) and the SC-NF. A main part of this disclosure is new interfaces and signaling parameters exchanged over the new interfaces.

In particular, the new interfaces may include:
An interface between the device and the SC-NF (e.g., Intf_SC-NF2Dev).

The first main function of this interface is that a user of a device may use this interface to manage its devices at the SC-NF. In specific, for device management, a user may use this interface for device registration, update and de-registration as shown in the exemplary embodiments. Signaling parameters may include:.

All these parameters associate to individual devices that are identified by device identifiers (i.e. DEV_IDs).

The second main function of this interface is that a device may use this interface to create a SC request with SC-NF. In specific, signaling parameters may include:.

The composition workflow defines a set of triggers (events, conditions) about the state of specific devices and/or environment and (a set of) actions that will be performed when the events happen.

The third main function of this interface is to deploy a composed service to the registered devices. In specific, signaling parameters include:.

The status may be proactively reported from or inquired at the device. The status may indicate the run-time data of the device such as incurred consumptions (e.g. physical resource / tariff resource), connectivity quality (e.g. packet lost, bandwidth and latency) and so on.

It can be seen that, the embodiments of this disclosed invention bring the following key benefits.

To the users/devices, it provides a unified view of the devices for the users/devices, which are scattered in existing paradigm scheme where the service providers control and manage the devices separately. Within existing schemes, it is difficult to have an overall view as brought by the SC-NF.

It further provides new types of services that can be customized by individual device. Within the provider-centric paradigm, a new service is created by the service provider rather than the user, this largely limits the variety of the service market. A user/device is restricted by service providers who decide what kinds of services will be available.

More importantly, it provides a self-sovereign domain where a user/device may fully control how the devices work together. This largely mitigates the privacy branching issues, data ownership issues and so on. The key reason is that the propose SC-NF becomes a service hub that is only accessible to its actual owner. In this case, a user or user device, e.g. user entity <NUM> may easily design necessary logics such as encryption logic, cryptographical hash logic and so on to protect their own data; even personalized cloud storage utilization can be added when sending data to multiple cloud drives. However, in existing provider-centric paradigm, there is no such a self-sovereign domain for a user. All services are directly provided at providers' domain, otherwise a user/device cannot use their services.

This disclosure is also meaningful to service providers. First of all, it enables the possibility that a user/device may customize new service. This brings benefits to the service providers in the sense of service variety. It not only implies new service capability, but also means new business opportunities. Users may be attracted by the new service capability, which gives them more controllability. User may be also willing to pay for the new service capability.

An additional benefit is that this embodiments of the present invention disclosure potentially improves general data protection regulation (GDPR) compliance for service providers. The reason is that an SC-NF acts like a middlebox, which is owned and controlled by the user/device, to store personal data in a secure manner. This eliminates the current way that a device directly uploads its personal data to the domain of a service provider (e.g. a cloud storage). When the data is needed by a third party, it has to get an approval by the device in order receive the data from the SC-NF. Such a model improves accountability of the whole system, which is again GDPR requirement. In principle, with an SC-NF, a service provider does not have to store personal data from all its devices.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Moreover, it is realized by the skilled person that embodiments of the network entity <NUM> or the user entity <NUM> comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Claim 1:
A method (<NUM>) for composing a service in wireless network, the method comprising:
receiving (<NUM>), by a service composition function, SCF (<NUM>), a request from a first device (<NUM>), wherein the request is used to prescribe synthesized functionalities provided by one or more second devices (<NUM>) to form a first logical device;
generating, by the SCF, configuration information based on the request from a first device, wherein the configuration information specifies a set of actions and/or parameters for forming the first logical device, wherein the configuration information is decomposed into detailed configurations for each of the one or more second devices with logical relationships, interface parameters, and collaboration policies; and
providing (<NUM>), by the SCF (<NUM>), the configuration information to each of the one or more second devices (<NUM>) to form the first logical device.