..just turning this into a technical thread 😉 Terminology-wise: MUP-C and mobile communication system control plane need to share an API. So, IMO, ’consume’ or ‘leverage’ is a good term.
Technically, the draft focuses on what happens southbound to the MUP-C. For the API between the MUP-C and the mobile communication system control plane I see another draft applies here and can complement the MUP architecture draft: https://datatracker.ietf.org/doc/draft-liebsch-dmm-mts/ The current revision defines a clear scope which is the API between (i) transport controller (or a dedicated application built on top), such as the MUP-C or the Mobile Traffic Steering Controller the mentioned draft, and the mobile communication system’s control plane. The same API may apply in between the a routing function and the mobile communication system’s user plane anchor. The current API semantics (which is under development) can be enriched with session information where the MUP-C derives routing information from. Just a thought, where we would be happy about other views and feedback. marco From: David Lake <[email protected]> Sent: Mittwoch, 21. Mai 2025 11:15 To: Marco Liebsch <[email protected]>; Sri Gundavelli (sgundave) <[email protected]>; [email protected] Subject: Re: Call for Adoption: draft-mhkk-dmm-mup-architecture as a DMM Working Group Document I support the WG in adoption of draft-mhkk-dmm-mup-architecture. I think there is a syntax problem in 6.3 though: Current: “A MUP Controller (MUP-C) provides an API. A consumer of the API inputs session information for a UE or a MN from mobile service system. “ I am not sure that the MUP-C does ‘provide’ an API as much as consumes an existing API from the mobile packet core, e.g. N4 to provide GTP<->UE mapping. But I don’t think we should specify N4 as an implementation may decide to directly integrate to the SBA over Nsmf or some future API. My suggestion is: “A MUP Controller (MUP-C) consumes an existing API from the 5G Packet Core which provides it with UE and/or MN session information.” David From: Marco Liebsch <[email protected]<mailto:[email protected]>> Date: Wednesday, 21 May 2025 at 09:52 To: Sri Gundavelli (sgundave) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [DMM] Re: Call for Adoption: draft-mhkk-dmm-mup-architecture as a DMM Working Group Document I support the WG in adopting such work and taking this draft as adopted base document. marco From: Sri Gundavelli (sgundave) <[email protected]<mailto:[email protected]>> Sent: Montag, 12. Mai 2025 02:14 To: [email protected]<mailto:[email protected]> Subject: [DMM] Call for Adoption: draft-mhkk-dmm-mup-architecture as a DMM Working Group Document Dear All, The authors have presented the Mobile User Plane (MUP) Architecture document in several DMM working group meetings. Based on the discussions and feedback received, the chairs believe there is some interest in this work and would like to confirm that view. Mobile User Plane Architecture for Distributed Mobility Management https://datatracker.ietf.org/doc/draft-mhkk-dmm-mup-architecture/ Standards Track We are now asking the working group to review and comment on this document. Please provide clear and substantive feedback indicating whether you believe this work should be adopted by the WG or should not, along with your reasoning. If there is sufficient interest and no objections from the AD, IESG, or others, we may move forward with adoption. The adoption call will end on 25th of May 2025. Regards Sri Cisco Confidential
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
