Don't forget there are some Application Notes at Semtech site (AN10, AN13 as well as AN14) that specify interfaces (JSON) and data model between Gateway and NS and between NS and AS.
Do you think the model you're writing down could become another profile for the LoRaWan specification? The whole spec could thus be enhanced with some profiles the R1.0 being the base profile.
Now, it could be useful for you and for us that you show the exchange that can occur between all the elements (handler, broker, router, etc) by detailing Use Cases and using a notation like UML.
That could help everyone to understand what are the flows, what they are about, what they contain, if they are encrypted or not, what are their end points and if they are justified or not.
Something useful would be a sample of pseudo code for what a element is responsible of (or a UML sequence diagram).
Domains of responsibility should be drawn on the architecture diagramm as well as protocols involved.
Some other points maybe irrelevant at this time:
- I can't see why routers should talk MQTT for example: a router routes (IP, IGP, EGP, BGP, etc) and makes decision based on routing tables but doesn't speak apps languages like MQTT is;
- is the handler really needed since, like the AS, it needs AppKey? Does the handler exist in the case of a customer would want to delegate?
Regards,
db