Handle high priority access service request as data

[donivtech]

What

Handle NAS Service Request service type 5 (high priority access,
TS 24.501 §9.11.3.50) as data instead of rejecting it.

Previously service type 5 fell through to the default case in
HandleServiceRequest and returned "service type[5] is not supported",
causing the AMF to send a Service Reject.

Why

High priority access is a valid service type. The AMF implements no
MPS/priority semantics, so there is no priority behaviour to preserve;
handling it the same as service type 1 (data) is correct and avoids
rejecting otherwise-valid requests. This also accommodates modems that
send service type 5 for ordinary data sessions (e.g. Xiaomi M11 Lite 5G /
Qualcomm, some Quectel firmwares), which otherwise cannot recover from idle.

How

Add a case nasMessage.ServiceTypeHighPriorityAccess that logs and falls
through into the existing ServiceTypeData handling. No config, no
behavioural change for any other service type.

Testing

• go build ./..., go vet ./..., go test ./... all pass
• gofmt clean, golangci-lint clean on the change

[Copilot]

Pull request overview

Updates AMF NAS Service Request handling so that NAS Service Request service type 5 (“high priority access”, TS 24.501 §9.11.3.50) is treated equivalently to service type 1 (“data”) instead of being rejected as unsupported.

Changes:

• Add explicit handling for nasMessage.ServiceTypeHighPriorityAccess.
• Log when service type 5 is received and fall through into the existing data service path (ServiceTypeData), avoiding a Service Reject.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gab-arrobo]

@donivtech, please address Copilot's comment and rebase PR. Thanks!

[donivtech]

Thanks for the review. Addressed both points:

• Added a unit test TestHandleServiceRequestHighPriorityAccessHandledAsData in gmm/handler_test.go. It table-tests HandleServiceRequest for service type 5 (handled as data), service type 1 (baseline), and an emergency service type as a control (still rejected via the default case). It drives the UE down the data path's tracking-area-mismatch branch, which only the data case performs, so reaching it confirms service type 5 falls through to the data handling rather than returning "service type … is not supported".
• Rebased onto the latest main.

go build/vet/test ./..., gofmt, and golangci-lint are all clean.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[donivtech]

Addressed the follow-up: the test now asserts the exact outcome per case instead of only checking for the absence of the "not supported" string — err == nil for the data and high-priority-access cases, and a non-nil error containing "is not supported" for the emergency control case. This removes the false-positive window where an unrelated error on the data path would still have passed. Tests, gofmt and golangci-lint remain clean.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.