Skip to content

MEC 030 - MQTT Subscription Scope and Hardcoded Notification Handling

Problem Summary

The current MQTT subscription and message handling logic are too restrictive and partially hardcoded.

Details

  1. Subscription Scope (etsi-mec-sandbox/go-packages/meep-vis-traffic-mgr/mqtt.go file)
token = broker_mqtt.client.Subscribe(tm.topic+"/+", 0, nil) // qos:0
  • The + wildcard matches only one sub-level under tm.topic.
  • Effectively, only two-level topics are captured (e.g., v2x/cam, v2x/denm).
  • Any deeper hierarchy (e.g., v2x/cam/eu) or single (e.g., v2x) is ignored.
  • It is unclear if this was intentional or if the subscription should instead cover all sublevels using tm.topic+"/#" or single.
  1. Hardcoded Notification Handling (etsi-mec-sandbox/go-packages/meep-vis-traffic-mgr/mqtt.go file)
if msg.Topic() == "3gpp/v2x/obu/vam" { // FIXME: Need to manage how to extract message type & message version
    _v2x_notify(msg.Payload(), 16, 2, "ETSI", nil, nil)
}
  • The topic and notification parameters are hardcoded (message type = 16, version = 2, org = "ETSI").
  • This prevents support for multiple V2X message types (e.g., CAM, DENM, MAPEM, SPATEM).

Proposed Resolution

  • Subscription Logic

    • Clarify whether tm.topic+"/+" is intentional.

  • Notification Handling

    • Dynamically parse the topic (and/or payload) to determine message type, version, and standard organization.
    • Avoid hardcoded values so multiple message types can be handled.