I'm thinking about to implement a couple of GATT services for a custom app, but I'm stuck right now in the research. I know that the service uuids are not random, some parts are well defined, others are still confusing me.
E.g. The Device Information Service seems to be advertised as 0000180a-xxx the "180a" I can find in https://www.bluetooth.com/specifications/gatt/services/, but e.g. the subfield "Model Number String" has the id 00002a24-xxx, a total different prefix which is also not defined in the same list, but instead here: https://www.bluetooth.com/specifications/gatt/characteristics/. How can I get a list of all those prefixes?
Is that part I marked with xxx seems to be equal for a random device my mobile found. Is there somewhere a overview how the uuid should be build and which "safe" prefixes I can use for my own GATT services?
In Bluetooth, attributes types, GATT service types, characteristic types and descriptor types, and other constants are identified through UUIDs.
UUIDs are no more than identifiers, 128-bit identifiers. One given 128-bit value designates one given thing. Using 128-bit random values gives minimal chances of collisions for two parties generating identifiers on their own, without the need for a central registry.
Bluetooth standard-defined UUIDs receive special treatment as they are commonly used throughout the various protocols of the Specification. They are grouped around the Bluetooth Base UUID (xxxxxxxx-0000-1000-8000-00805F9B34FB) and share 96 common bits. (See core specification, 3.B.2.5.1)
In various protocol parts, standard UUIDs can be transmitted in a short form, skipping the common bits, thus only using 16 or 32 bits on the air. This is an implementation detail, specific to some protocols in the whole stack. Because of this, standard-defined UUIDs are often referred as Short UUIDs.
Apart from standard UUIDs, any implementor is free to generate its own UUIDs from 128 bits of random and use them anywhere needed. Custom UUIDs must not use the Bluetooth Base UUID (and cannot be encoded in a short form, but you should not care about this).
Use Standard UUID when implementing standard services and characteristics.
Never use Bluetooth Base-UUID based UUIDs for custom purposes.
When developing your custom service and attributes, reusing existing UUIDs (or part of UUIDs) from code you may find in example code, vendor SDKs, or anywhere else is not a good idea. You should really regenerate yours.
Specification does not define any grouping scheme (what you call prefixes) for custom UUIDs, but some vendors do incitate to group custom UUIDs, in a way they generate one 96-bit custom base UUID, and issue incrementing values from this, as Bluetooth did. This is not standard and brings no protocol optimization.