-
Notifications
You must be signed in to change notification settings - Fork 10
Continuing Development
Once the SAS is at a stable release, some comments on how to improve current processes as well as functions will be provided. Of course the direction of development shall go in the way of Dr. Dietrich or whoever else is an "owner" of this, but some insight from the architects of the project may be of use.
The CORENET client to the SAS provides some level of user entered data validation. It ensures that to some degree, the user input (via terminal or simulation file) is not invalid. In order for this client to be even better, there must be great effort towards calibrating the USRPs and taking note of the daughter-board on each node and considering their capabilities. For example (these are fictitious example numbers), some daughter-boards may allow TX up to 10GHz while others may be up to 2200MHz (which does not reach CBRS band). The client code should seek out these limitations and apply them as users attempt to create nodes and/or alter the operating parameters. Information on limitations may be found by using uhd_usrp_probe --args="<usrp_ip_address>".
- No known Python API to
uhd_usrp_probeexists, unlike howuhd.find_devices()exists. It would be great to create such API so that the script can always check what the USRPs are capable of before allowing a user to blindly choose a USRP that may not even operate with the grant it requests. There is no handling for this at the moment. Currently, the user is supposed to be aware of the USRP limitations and ensure not to register a Node that will not be compatible with the CBRS band.
The USRPs are not calibrated, meaning different nodes may report different dB values when they should all agree in certain instances. It would be extremely beneficial if a developer created a calibration script that would:
- Turn on a RF Generator with known output power, and feed the output directly into a USRP.
- Provide the USRP with the calibration parameters and have it calibrate to the known source.
- USRPs must be calibrated per frequency, so the generator and USRP must sweep to calibrate completely.
Some aspects of the WinnForum Technical Specifications were not utilized in this creation of SASv1.0 [1].
Section 8.1 of [1] mentions how the SAS server is publicly listed on DNS servers. The WinnForum appears to suggest to have a URL in which the SAS server may be publicly reached. Placing the SAS Server on a public server, that is reachable without remote logging into the VT/CORENET sever, would be an advancement in providing an "open-source" SAS.
Section 8.2 of [1] outlines the need for TLS mutual authentication for the SAS and CBSDs/Domain Proxies. This is an opportunity for further development. SASv1.0 simply utilizes a direct socket connection for SAS-CORENET message transport. Section 9.2 of [1] mentions an HTTPS implementation for SAS-CBSD message transportation. An example POST is shown with the URL/resource path syntax included.
Section 9.3 of [1] mentions the use of digital signatures. The CPI objects are already created, however not yet implemented.
Section 8.3.2 of [1] mentions the suggested behavior of a CBSD when it receives a "REG_PENDING" response from the SAS after a Registration Response. A persistence in sending Registration Requests has not been implemented and may prove useful.
In the event that a Grant response does not indicate a fulfilled grant request, the SAS my provide a new set of operation parameters (operationParams). As of SASv1.0, these parameters are printed out and no further action is taken. The WinnForum suggests that the CBSD "decide" if the new operation parameters are sufficient for the node's request, and if so, send a new Grant Request with the new parameters.