Yes, in principle it is possible to adopt this kind of policy in the network controller. It can even be a policy which is applied specifically by end-device, meaning that a pool of end-devices could be acknowledged on Rx1, and others on Rx2.

The network server and application server are software entities that control higher level aspects of a LoRaWAN application. The gateway and end device look after the physical layer connection, the network server looks after the protocol and the application server looks after the application level control and data. All are required.

Semtech is actively looking at all options for improving the performance offered to all licensees. Semtech has been in active development both internally and with third parties up to the point of the first release and this is expected to continue. Semtech does not believe that the common solver approach will best serve the specific use cases of all users so is expecting Licensees to integrate multiple solvers some of which might be application specific in order to cover the needs of the wider use cases. 

Semtech has built a system upon which development and differentiation is expected in the market place. Licensees are given the source code for Semtech’s solver. The Licensee is then entirely at liberty to use any means to improve the solution to reach the performance that is important to the use cases that drive the Licensee’s business. The Licensee can choose whether to invest development resources, sub-contract, purchase I.P. or rely on Semtech. 

Semtech has built ‘base camp’. This is a generalised solver without any knowledge of the application of the sensor. There are many ways that the solution could be improved such as knowing if and when a sensor moves, bursting several packets rapidly, knowing any geographic constraints such as ‘stick to roads’ etc. etc.

With the release of version 1, Semtech is involving the partners in the eco-system to build more networks, capture data and develop the solution to fit various use cases. 

Semtech will make the updated solvers available directly to the licensees of the Location service. This, in general is the system integrator. Semtech makes the solvers available as source code and, following receipt, the system integrator will choose whether to integrate the new version into their product. Since the solver is provided in source code, it is expected that the development of the solvers are not limited to the work conducted within Semtech. It is expected that third parties will become involved and create differentiation in the market place. Therefore, the schedule of updates should be discussed between the end user and the provider of the location service.

Actility and a lot more via the ThingExchange Peering Hub

They will have to make sure they are using a NS that has passed interop testing with the Semtech JS. Subsequently,  they should go through interconnection setup (an IT procedure). Semtech JS is already connected to Actiliy's peering hub platform, ThingPark Exchange. Any network that is connected to ThingPark Exchange can be readily interconnected with the Semtech JS. Others will have to go through individual interconnection setup.

API details can be found in the LoRa Edge Tracker Reference Design User Guide