Closed grant-h closed 2 years ago
Thanks for your feedback.
Unfortunately, comments are stripped early in the text processing, while calling clean_text()
defined in https://github.com/P1sec/pycrate/blob/93ab3bfbd7176ce64fefb6707085c48d4156cb0a/pycrate_asn1c/utils.py#L471
I agree that catching those kind of meta-definition would be nice. However, comments notation and formatting are..... unspecified, and there is no common rules on how to catch them ! What I would personally do is to develop an adhoc routine (eventually just with grep / awk) to catch those and write them in a file in a simple format. Then in Python, after you load the LTE RRC module, you can use this file to retrieve those meta-definition and apply further checks on ASN.1 objects.
3GPP has a loosely followed convention of annotating OPTIONAL fields in the RRC UE downlink messages to indicate to implementors what action should be taken (if any) when a field is not present. Here's an example:
field1
, Optionally Present (OP) is specified, which just indicates that the field description should be read to learn how to handle this case.field2
has Optionally present, No action (ON), which means if the field is missing the last known value of the field (as received in a previous IE with this field present) should continue to be used.field3
Optionally present, Release (OR) indicates that unlike ON, if the field is missing, it will be released and the functionality associated with it will be disabled. This means the field should to be sent for each DL message containing this IE, unless the NodeB wants it released.field4
, the IE is conditionally present based off ofsomeCondition
where some condition is further specified in the field description.Since this is a bit of a hack on the 3GPP's part, I'm not sure what the best way is for pycrate to handle this metadata (if at all). I do believe it would be useful to capture this information during ASN.1 compilation though or maybe provide some guidance/script to walk the ASN.1 AST to capture and associate this information with types. Frankly grep would probably get pretty far on its own, but having it be typed would be a bonus.
See 3GPP TS 36.331 version 16.2.1, rel 16, Section 6, Table 6.1-1 for more details.