Another issue when modelling in VCC is the use of data structures which are kind of an abstraction from the raw bytes that are described in the specification. This of course eases the understanding of symbols and the process of making changes to data types and interfaces, but it is unlike any real life implementation where there is only dealt with raw data and there is therefore easier integration with other devices (in real life any two implementations of different layers should be able to inter operate, whereas in our simulation environment we have logical ports that have to agree on data types etc.)
The validation of correctness of the protocols is not an easy task when dealing with something as big as the LMP and the HCI. Luckily an implementation of LMP can be a subset of all that is described in the specification and thus the implementation has been cut down to what is relevant in a simulation environment. Each command has been tested with a simple test harness so that upon correct use, the correct behaviour can be observed. Also every possible error event that can be generated for each command has been provoked. This of course is in no way an exhaustive test of the protocol but signifies that upon correct use, the behaviour is correct. An exhaustive test would have to include all permutations of the commands, extensive tests of parameter values plus testing if something might possibly go wrong with the buffering of commands and data when many devices speak to each other simultaneously. A test harness that did any of this would most likely be bigger than the implementation of the protocol and as this would be too great a task for this course, my efforts have gone to make sure that the implementation works in our current protocol stack. I will, however, dare to estimate that my implementation follows the specification closely and I cannot think of any problems with integration with other protocols than the L2CAP. As for the downwards interface there really is no specification of an interface, which to me suggests that the Link Manager and Baseband really should be closer linked than they are in our protocol stack. The interface that is defined between Baseband and LM is thus fairly tight, and it would not be an easy task to replace the Baseband. If the Baseband ever needs replacement, I would rather suggest that at least the Link Manager should become part of it.