Patent Grant
10367696
This application is a 35 U.S.C. § 371 National Phase Entry Application from PCT/SE2016/050473, filed May 23, 2016, and designating the United States.
Aspects of this disclosure relate to systems and methods for network management.
The goal of increasing the degree to which a network is managed automatically is not new. Autonomic networks have been a subject of research over the last 15 years, and technologies for achieving network automation are evolving. Recently there have been advances in a few specific technologies that increase both the urgency to increase automation as well as the possibilities of doing so. For example, Network Function Virtualization (NFV) provides flexibility in how network functionality is deployed and where it is deployed, which is enabled by the increasing maturity of cloud execution environments to support large number of diverse workloads in either a centralized or distributed manner. Additionally, Software Defined Networking (SDN) enables networking flexibility and the means to provide connectivity (networking) to the deployed virtual or physical network functions. This is often referred to as programmable networking. Furthermore, analytics technologies have evolved to the state where they can provide advanced insights into the state of the network.
The increased flexibility provided by new technologies, such as SDN, has led to networks that are difficult to operate and require a high degree of manual intervention. Existing solutions to this problem tend to group together several functions to achieve a desired result. For example, existing solutions group together the means for producing insights (analytics), the means for selecting a recommended action based on insights (policy), and the means for executing the recommended actions. Some such existing solutions merely rely on a script to produce the insights, make the recommendations based on the insights, and then perform the recommended actions. Such scripts are rather inflexible and typically need to be manually modified in the event the recommended action does not produce the intended result or the inputs to the script change. Additionally, because such scripts tightly couple the implementation of the required functions it is very difficult to change one of the functions (e.g., analytics or policy) without a major impact.
Described herein is a network management architecture referred to as the Control/Orchestration/Management/Policy/Analytics (COMPA) architecture (or COMPA for short).
The COMPA architecture functions to simplify and automate the operations (both management and business process) of a network. In one aspect, the COMPA architecture addresses four use case categories: (1) Resource/Service Onboarding; (2) Automated Product Offerings; (3) Automated Management; and (4) Service Exposure. COMPA enables rapid service introduction into the network and lifecycle management; dynamic network governance via policy; and controlled access to functionality provided by different responsibility domains.
In some embodiments, these results are achieved through the following: (1) an architectural pattern for advanced automated management called the “COMPA-Loop”—the architectural pattern comes with a set of COMPA agents that can be applied at various levels in the network architecture (it is expected that these agents can be implemented with re-usable components); (2) an enterprise wide policy framework for policy definition, deployment and execution of service and resource policies; (3) architectural patterns for a higher level of automation of resource onboarding and service onboarding, based on policy-driven workflow orchestration; and (4) Analytics based on a common architecture and interfaces.
In one embodiment, the COMPA architecture includes four agents that each provide a unique set of functionality. These four agents are: (1) a Control, Orchestration and Management (COM) agent; (2) a policy agent; (3) an analytics agent; and (4) a Resource Domain Common Functions (RDCF) agent.
The COM agent may be configured to perform requested actions, such as, for example, actions requested by a policy agent and actions for supporting resource and service onboarding requests. In some embodiments, the policy agent functions to request a COM agent to perform certain actions based on, for example, insights received from an analytics agent. An analytics agent may be configured to provide insights (i.e., reports), such as insights identifying current (and/or predicted) events or conditions within the network. In some embodiments, an RDCF agent provides service exposure, maintains catalogs (e.g., a service catalog and/or a resource catalog), and maintains inventories.
In one specific aspect, a COMPA system is provided that includes a first analytics agent; a first policy agent, and a first COM agent. The first analytics agent is configured to: collect data from various data sources, process collected data into insights, and provide requested insights to a consuming agent (e.g., the first policy agent) in response to receiving from the consuming agent a report request identifying a requested insight type. The first policy agent is configured to request the first analytics agent to send to the first policy agent one or more insights. In some embodiments, the first policy agent is configured such that, in response to receiving a set of one or more insights from the first analytics agent, the first policy agent uses a policy and the one or more insights to determine whether a first action should be taken, and, as a result of determining the first action should be taken, transmits to the first COM agent a first action request message for identifying the first action, and the first COM agent is configured such that, in response to receiving the first action request message, the first COM agent performs the requested first action.
In some embodiments, the COMPA system further includes a second analytics agent and a third analytics agent. The second analytics agent is configured to: collect data from various data sources, process collected data into insights, and provide requested insights to a consuming agent in response to receiving from the consuming agent a report request identifying a requested insight type. The third analytics agent configured to: 1) request the first analytics agent to send to the third analytics agent one or more insights generated by the first analytics agent, 2) request the second analytics agent to send to the third analytics agent one or more insights generated by the second analytics agent, and 3) generate at least one insight based at least in part on one or more insights transmitted to the third analytics agent from the first analytics agent and one or more insights transmitted to the third analytics agent from the second analytics agent.
In some embodiments, the COMPA system further includes a second policy agent configured to request the third analytics agent to send to the second policy agent one or more insights generated by the third analytics agent based at least in part on one or more insights transmitted to the third analytics agent from the first analytics agent and one or more insights transmitted to the third analytics agent from the second analytics agent.
In some embodiments, the COMPA system further includes a second COM agent. In such an embodiment, the second policy agent may be configured such that, in response to receiving a set of one or more insights from the third analytics agent, the second policy agent uses a policy and the one or more insights received from the third analytics agent to determine whether a second action should be taken. And, as a result of determining the second action should be taken, the second policy agent transmits to the second COM agent a second action request message for identifying the second action. The second COM agent is configured such that, in response to receiving the second action request message, the second COM agent performs the requested second action.
In some embodiments, the COMPA system includes a plurality of responsibility domains (RDs) comprising a first RD and a second RD. In some embodiments, the first analytics agent, the first policy agent, and the first COM agent are part of the first RD but not part of the second RD, and the third analytics agent, the second policy agent, and the second COM agent are part of the second RD but not part of the first RD. The plurality of RDs may further include a third RD and the second analytics agent may be a part of the third RD but not a part of the first or second RD.
In some embodiments, the first policy agent is configured to request the first analytics agent to send to the first policy agent one or more insights by transmitting to the first analytics agent a report request message. In some embodiments, the report request message includes: a report type identifier identifying a requested report type; and time interval information specifying the periodicity with which the first analytics agent should send to the first policy agent a report of the requested report type. The report request message may further include an object identifier specifying a target object. The target object may be one of: an identified subscriber, an identified group of subscribers, an identified service, and an identified network element.
In some embodiments, the first analytics agent is configured to transmit to the first policy agent a real-time insight in response to detecting that a load on a service has met or exceeded a threshold. In such an embodiment, the first policy agent can be configured such that, after receiving the real-time insight, the first policy agent determines whether more resources should be added to the service. Additionally, the first policy agent can be configured such that, in response to determining that more resources should be added to the service, the first policy agent transmits to the first COM agent a message requesting that the first COM agent add more resources to the service.
The above and other aspects and embodiments are described below with reference to the accompanying drawings.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.
As further shown in
In some embodiments, COM agent 208 is configured to perform requested actions, such as, for example, actions requested by a policy agent and actions for supporting resource and service onboarding requests. Thus, in some embodiments, COM agent 208 is configured to receive action request messages that request COM agent 208 to perform actions, such as, for example, onboarding of resources and/or services.
In some embodiments, a resource can be any one of: a network function (e.g., Mobility Management Entity, Serving Gateway, etc.), switching/routing equipment, computing resources, storage resources, a COMPA agent.
In some embodiments, policy agent 206 functions to request a COM agent, such as COM agent 208, to perform certain actions based on, for example, a policy decision that policy agent makes based on, for example, insights received from an analytics agent, such as analytics agent 202 or an analytics agent in another COMPA system in another RD. Accordingly, policy agent may be configured to transmit insight request messages to an analytics agent and transmit action request messages to a COM agent. Additionally, policy agent 206 may be configured to receive from a COMPA system agent (e.g., a COM agent) or a non-COMPA system policy event messages that contain information for use by policy agent in making the policy decision.
In some embodiments, Analytics 204 agent is configured to provide insights (i.e., reports), such as insights identifying current (and/or predicted) events or conditions within the network. For example, in some embodiments, analytics agent 204 is configured such that, in response to receiving a historical insight request message, analytics agent 204 periodically transmits an historical insight to the requesting entity, which is typically a policy agent, and is further configured such that, in response to receiving a real-time insight request message, analytics agent 204 immediately transmits an insight to the requesting entity.
In some embodiments, RDCF agent 202 provides service exposure, maintains catalogs (e.g., a service catalog and/or a resource catalog), and maintains inventories.
Analytics Agent 204 Messages
As explained above, analytics agent 204, in some embodiments, is configured to act on certain defined messages. In some embodiments, these messages include the following messages: 1) the historical insight request message; 2) the real-time insight request message; 3) an historical insight tuning message; and 4) an historical insight termination message. The below tables (Tables 1-4) illustrate the information elements that may be included in each of the messages:
With respect to the historical insight request message, as a result of receiving this message, analytics agent 204 creates in a database a record storing information contained in the received message (e.g., the periodicity, report type, etc.) and transmits to the entity that transmitted the request an acknowledgement message containing a delivery identifier for use in later retrieving the database record from the database. Also, as a result of receiving the historical insight request message, analytics agent 204 will, based on the periodicity defined in the request, periodically transmit an historical insight delivery message comprising an insight. The transmitted historical insight delivery message may further include the identifier that was included in the acknowledgement message. The insight included in the historical insight delivery message may be formatted using a markup language (e.g., Extensible Markup Language (XML)) or using JavaScript Object Notation (JSON)) or otherwise formatted.
With respect to the historical insight tuning message, as a result of receiving this message, analytics agent uses the delivery identifier included in the tuning message to update the database record based on the parameters included in the tuning message (e.g., the periodicity parameter).
With respect to the historical insight termination message, as a result of receiving this message, analytics agent uses the delivery identifier included in the tuning message to delete the database record or update the database record to indicate that no further historical insights defined by the record should be sent.
With respect to the real-time insight request message, as a result of receiving this message, analytics agent 204 generates a real-time insight and transmits a real-time insight delivery message comprising the generated real-time insight. In some embodiments, after the insight request message is received and before the delivery message is sent, analytics agent 204 transmits an acknowledgement message with a delivery identifier, and the delivery message includes the delivery identifier. The insight report may be formatted using XML or JSON and contains information (e.g., real-time information) requested in the real-time insight request message.
Policy Agent 206
Policy agent 206, in some embodiments, is configured to act on certain defined messages. In some embodiments, these messages include: 1) a policy data message; and 2) request policy decision message. The below tables (Tables 5 and 6) illustrate the information elements that may be included in each of the messages:
With respect to the policy data message, this message can be transmitted to the policy agent by any resource in the network. As a result of receiving this message, policy agent 206 may store the event report (or stores at least some of the information included in the event report) so that the information can be used at a later time as input to a policy statement executed by policy agent 206, or policy agent may execute a policy statement based on the event report immediately after receiving the policy data message. As one example, a resource (e.g., a security system which may or may not follow COMPA principles) sends a policy data message to the policy agent with an event report containing information informing the policy agent about a detected denial of service attack, and the policy agent acts on this information immediately by, for example, determining based on a policy statement a set of or more actions that should occur.
With respect to the request policy decision message, as a result of receiving this message, policy agent 206 uses the information contained in the Policy Decision Input IE (and possibly previously stored event report information) to execute a policy statement, and thereby make a policy decision. An identifier identifying the policy statement may be included in the Policy Decision Input IE together with parameters required by the policy statement. In some embodiments, the result of the policy decision is returned to the entity that transmitted the request policy decision message.
In some embodiments, as a result of executing a policy statement, the policy agent may be triggered to send to a COM agent a Request Action message.
COM Agent 208
COM agent 208, in some embodiments, is configured to act on certain defined messages. In some embodiments, these messages include the message identified in TABLE 7.
Tables 8 to 17 below illustrate an exemplary embodiment of the COM agent messages shown in table 7.
RDCF Agent 202
RDCF agent 202, in some embodiments, is configured to act on certain defined messages. In some embodiments, these messages include the message identified in table 18 below.
Tables 19-40 illustrate the information elements that may be included in each of the messages show in TABLE 18.
Table 41 below illustrates an exemplary embodiment of the C_Service Capability Discover Response.
Use Case Categories
There are numerous possible uses cases for the COMPA system. In some embodiments, each use case can be categorized into one of the following four categories: Resource/Service Onboarding; Automated Product Offering (APO); Automated Management (AM); and Service Exposure (SE).
Resource/Service Onboarding:
In some embodiments, before a product (i.e., service) can be offered automatically using COMPA, the service and the resources required by the service must first be onboarded, which means that the specification for the service and the specification for each resource required by the service must be registered with an RDCF agent. This is referred to as Resource/Service Onboarding. Additionally, the resources required to instantiate the service must be instantiated (i.e., made operational) in response to a request to instantiate the service or must have been previously instantiated. That is, some resources will be instantiated when the service is instantiated (e.g. setting up a new network for a special type of service, how to setup the resources is not known before the service request is received), while other Resources that were instantiated before the request to instantiate the service is received may require a re-configuration for the service when the service is instantiated. Some resources will be also instantiated during operation to add more resources to cover an increase in load.
Resource/Service Onboarding includes: the deployment of service and resource specifications and the deployment of some resource instances. A service specification describes the services offered by the service and the elements (e.g., resources) that are needed in order for the service to provide the services the service offers. Accordingly, in some embodiments, service specifications identify (e.g., contain links to) resource specifications. Accordingly, in some embodiments, before a particular service specification is deployed, the resource specification identified by the particular service specification should be deployed first, if they are described as required to be instantiated in order to later instantiate the service. During instantiation of resource instances the applicable resource specifications are used. The resource instances describe what has been instantiated, the description includes which service or resource instance it supports and which resource instances it uses. Instantiation of a service is part of Automatic Product Offerings (APO), which is described in the next section, and may imply the instantiation of more resources.
The service descriptor may also include information describing the relationships, if any, between the identified resource specifications. For example, the first resource specification identifier may identify a specification for a first type of network node (e.g., Serving Gateway (SGW)) and the second resource specification identifier may identifier a specification for a second type of network node (e.g., a Mobility Management Entity (MME)). In such a scenario, the service descriptor may include information indicating that SGW must be allocated in IP address and the MME must be configured with configuration information that identifies the IP address assigned to the SGW so that when the MME and SGW are instantiated the MME will be able to communicate with the SGW over an IP network.
The COM agent 208 is configured such that, in response to receiving the DSS message, COM agent 208 determines, for each resource specification identifier included in the set, whether the resource specification identified by the resource specification identifier is maintained by at least one RDCF agent. Accordingly in step 304, COM agent 208 transmits to RDCF agent 202 a first Resource Specification Discovery (RSD) message containing the first resource specification identifier, and in step 306 COM agent 208 transmits to RDCF agent 392 a second RSD message containing the second resource specification identifier. Assuming the identified resource specifications have been previously registered with RDCF agents 202, 392, respectively, then the RDCF agents 202, 392 will respond to the respective RSD with a respective positive acknowledgement (e.g., a message comprising a pointer to the identified resource specification or comprising the resource specification itself).
COM agent 208 is further configured that, once COM agent 208 determines that each resource specification identifier included in the set identifies a resource specification that is maintained by at least one RDCF agent, COM agent 208 registers the service specification included in the DSS received from OSS 389. That is, in step 308, COM agent 208 transmits to RDCF 202 a Service Specification Registration (SSR) message comprising the service specification obtained from OSS 208.
After receiving the message, COM agent 208 obtains the resource specification (extracts it from the message or uses the pointer to download it) and then parses the specification to determine information about the resource specified by the resource specification. For example, the specification may indicate that the resource should be implemented as a tenant of a multi-tenant software application. Assuming that the specification indicates that the resource should be implemented as a tenant of a multi-tenant software application, COM agent 208, in step 406, sends to an RDCF agent (in this case RDCF agent 392) a Resource Instance Discovery (RID) message to determine whether an instance of the multi-tenant software application is operational.
In step 408, COM agent deploys the resource so that the resource will be operational. For example, in the case the resource is a tenant of a multi-tenant application, then in step 408 COM agent communicates with a controller of the multi-tenant application to instantiate a new tenant corresponding to the resource. This may include COM agent 208 transmitting one or more specific configuration files corresponding to the resource. As another example, in the case that the resource is a stand-alone application, then in step 408 COM agent 208 transmits to a platform for executing the resource information contained in the Resource SW information element of the resource specification corresponding to the resource (e.g., a binary executable file and/or configuration files).
After deploying a resource, COM agent 208 may transmit to RDCF 392 a Resource Instance Registration (RIR) message or a Resource Instance Update (RIU) message (step 410). RIR/RIU message may contain information about the deployed resource. This information about the deployed resource may contain, among other things, a service identifier identifying a service that the resource is supporting. As described above, RDCF 392, in response to an RIR message creates a resource instance registration records that includes information included in the RIR, including the service identifier. Similarly, RDCF 392, in response to an RIU message, updates the resource instance registration record to include information included in the RIU, including the service identifier. In this way, if a resource supports one or more services, the resource instance registration record for the resource will identify each of the one or more services. This information linking a resource to each service that the resource supports can be used by an analytics agent and/or a policy agent.
For example, an analytics agent (e.g., agent 202) may receive from an OSS a command to monitor a particular resource. In response, the analytics agent may send to the RDCF agent that maintains the resource instance registration record for the particular resource a request to provide the analytics agent with the information stored in the registration record (or a sub-set of the information, such as the list of services that the resource supports). By having knowledge of the services that the particular resource supports, the analytics agent can provide useful service information to a policy agent. For instance, if the analytics agent determines that the particular resource has become, or is on the threshold of becoming, overloaded, then the analytics agent can use the information obtained from the RDCF agent to determine the services that may be impacted by this event (i.e., the services that the particular resource supports) and then inform a policy agent not only that the particular resource is having a problem, but also can inform the policy agent that one or more identified services (i.e., the services supported by the resource) may be at risk of a performance degradation.
Similarly, a policy agent that receives from an analytics agent (or other entity) a report indicating that a particular resource is having a problem (e.g., an overload problem), the policy agent itself may send to the RDCF agent that maintains the resource instance registration record for the particular resource a request to provide the policy agent with the information stored in the registration record (or a sub-set of the information, such as the list of services that the resource supports). By having knowledge of the services that the particular resource supports, the policy agent can take an appropriate action for each service, such as, for each impacted service, instruct a COM agent to instantiate an appropriate resource for the service.
Automated Product Offering (APO):
APO is about automating the procedures required to instantiate a service into the network for a specific offering for specific (set of) users (this ranges from a service for an enterprise or services for a end-users). APO includes the instantiation of a service and instantiation/allocation of resources required for this service. The instantiated resources and services are registered in the resource and service inventory, respectively.
As a result of receiving the service specification, COM agent 208 determines, for reach resource specification identifier, whether the resource corresponding to the resource specification identifier has been instantiated (i.e., is operational for the service). This is accomplished by COM agent 208 sending to one or more RDCF agents one or more RID messages. Thus, for example, in step 506, COM agent 208 transmits to an RDCF (in this example it is RDCF 392) a Resource Instance Discovery (RID) message to determine whether the corresponding resource has been instantiated. For any such resource that has not been instantiated, COM agent 208 instantiates the resource (step 508) (e.g., COM agent may perform steps 404-408.
After ensuring that all of the required resources have been instantiated (e.g., after determining that every resource identified by the one or more resource specification identifiers included in the service specification has been instantiated), COM agent 208 registers the service instance by transmitting to RDCF 208 a Service Instance Registration (SIR) message (step 510).
Automated Management (AM)
AM (sometimes referred to as autonomic networks) is about automating the operational support of the network. The aim is to have a policy based control for managing the deployed and instantiated/assigned resources.
In step 606, analytics agent 204 process the data from the data sources to generate an insight 607 based on the data received from the one or more sources and transmits the insight to policy agent 206, which receives the insight. In some embodiments, the step of transmitting the insight includes one of: transmitting an historical insight delivery message comprising the insight and transmitting a real-time insight delivery message comprising the insight.
In step 608, as a result of receiving the insight (which may include network performance information and/or security information), policy agent 206 determines whether an action is needed based on information included in the insight and a policy. For example, in step 608, policy agent 206 may execute a rule contained in a policy and determine, based on the rule and information in one or more received insights, whether a certain condition has been satisfied (e.g., whether a certain processor utilization has stayed above a certain threshold for at least a certain amount of time). As a result of determining that a network management action should be undertaken, policy agent 206, in step 610, transmits to COM agent 208 an action request 612 (e.g., a “Request Action” message or an “Instantiate Resource” message, defined above) identifying at least one specific action. In step 612, COM agent 208 performs the requested action(s).
This use case is used to illustrate that an analytics agent 704 (see
Referring now to
In step 706, analytics agent 204 generates an insight based on data received from one or more resources and transmits the insight to analytics agent 704, which receives the insight. In step 708, analytics agent 702 generates an insight based on data received from one or more resources and transmits the insight to analytics agent 704, which receives the insight. In step 710, analytics agent 704 generates an insight based on the insights received in steps 706 and 708 and transmits the generated insight to policy agent 706.
In step 712, as a result of receiving the insight transmitted by agent 704, policy agent 706 determines whether an action is needed based on information in the insight and a policy. As a result of determining that an action should be undertaken, policy agent 706 transmits to COM agent 708 an action request identifying at least one specific action.
In some embodiments, an analytics agent (e.g., agent 204) is configured to transmit to a policy agent (e.g., agent 206) a real-time insight delivery message in response to detecting that a certain condition or event has been detected. For example, in response to detecting that a performance parameter (e.g., a load on a service) has met or exceeded a threshold or in response to detecting some other event or condition.
In some embodiments, policy agent 206 is configured such that, after receiving the real-time insight, the policy agent 206 determines whether more actions should be undertaken (e.g., policy agent execute a policy statement). For example, in response to receiving a real-time insight indicating that a load on a service has met or exceeded a threshold, policy agent 206 may be configured by a policy statement to determine whether resources should be added to the service and may further be configured such that, in response to determining that more resources should be added to the service, the policy agent 206 transmits to a COM agent (e.g., COM agent 208) a message requesting that the COM agent add more resources to the service (e.g., agent 206 transmits to agent 208 an Instantiate Resource message). As another example, in response to receiving a real-time insight indicating that a subscriber notification is required or that a subscriber should be blocked, policy agent 206 may be configured to send a message to a COM agent to cause the COM agent to provide a certain notification to the subscriber or block the subscriber.
In some embodiments, method 800 includes additional steps (see e.g.,
In some embodiments, the method also includes a second policy agent (e.g., policy agent 706) requesting the third analytics agent to send to the second policy agent one or more insights generated by the third analytics agent based at least in part on one or more insights transmitted to the third analytics agent from the first analytics agent and one or more insights transmitted to the third analytics agent from the second analytics agent. The second policy agent, in response to receiving a set of one or more insights from the third analytics agent, may use a policy and the set of one or more insights received from the third analytics agent to determine whether a second action should be taken, and, as a result of determining the second action should be taken, transmits to a second COM agent (e.g. COM agent 708) a second action request message for identifying the second action, and the second COM agent is configured such that, in response to receiving the second action request message, the second COM agent performs the requested second action.
As shown in
While various embodiments of the present disclosure are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.
Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2016/050473 | 5/23/2016 | WO | 00 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2017/204699 | 11/30/2017 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 20130046819 | Bocirnea | Feb 2013 | A1 |
| 20130267209 | Bott | Oct 2013 | A1 |
| 20140317261 | Shatzkamer et al. | Oct 2014 | A1 |
| 20160057075 | Parikh | Feb 2016 | A1 |
| 20160057234 | Parikh et al. | Feb 2016 | A1 |
| 20180316569 | Cilfone | Nov 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 2518942 | Oct 2012 | EP |
| 2013072232 | May 2013 | WO |
| 2015191965 | Dec 2015 | WO |
| Entry |
|---|
| International Search Report and Written Opinion dated Jan. 23, 2017 in International Application No. PCT/SE2016/050473, 14 pages. |
| International Search Report and Written Opinion dated Jan. 26, 2017 in International Application No. PCT/SE2016/050474 (U.S. Appl. No. 15/108,830)), 15 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20170339023 A1 | Nov 2017 | US |
