Liaison statement
LS Response on IETF Network Slice Application in 3GPP 5G End-to-End Network Slice

1. Overall Description:

SA thanks IETF TEAS WG for LS on “IETF Network Slice Application in 3GPP 5G
End-to-End Network Slice”. In the LS the TEAS WG request 3GPP to review the
document and verify if the description of the 3GPP 5G End-to-End Network Slice
is accurate, and if not, to provide suggested clarifications.

SA noticed that RAN3 has responded this LS directly to IETF TEAS WG in
R3-257304.

Based on input from SA WGs, SA would like to provide further feedback.

Feedback #1: CSMF (Communication Service Management Function), NSMF (Network
Slice Management Function) and NSSMF (Network Slice Subnet Management Function)
are mentioned multiple times throughout the document in [1]. SA5 would like to
clarify that CSMF, NSMF and NSSMF are non-standardized slicing management
functions, but deployment examples of Provisioning MnS producers and consumers
for network slicing management. Annex A.8 (informative) of 3GPP TS 28.533 [10]
provides a typical deployment example for management of a mobile network
including network slicing. For further information on network slicing
management, see 3GPP TS 28.531 [2].

Feedback #2: The concepts of “RAN Slice” and “Core/CN Slice” are mentioned
multiple times throughout the document  [1] (e.g., Figure 2, Figure 6, Figure
7). SA5 would like to clarify these concepts are not defined in normative
specifications, and suggests their alignment with the 3GPP definition of
Network Slice Subnet, as specified in clause 3.1 of 3GPP TS 28.530 [8].
Additionally, SA5 would like to clarify that the concepts of “Centralized RAN
Deployment” (clause 3.2) and “Cloud RAN Deployment” are not recognized by 3GPP

Feedback #3: With regards to Relationship Between IETF Network Slices and 3GPP
Network Slices (clause 3.4):

•       In page 9, there is a reference to Figure 6. SA5 would like to clarify
that this reference should be Figure 5 instead.

•       Figure 5 illustrates the relationship between 3GPP domain controllers
and IETF Network Slice Controller. SA5 suggests aligning this figure with the
terminologies used in the IETF Network Slice Management Architecture defined in
RFC9543 [11] and with the terminologies used in 3GPP TS 28.531 [2] (e.g., avoid
using non-3GPP concepts such as “RAN/AN NSSMF” and “CN NSSMF”). In addition,
SA5 suggests IETF to indicate in the figure what parts are out of IETF scope,
like as proposed in Annex A.8 of TS 28.533 [10] (e.g., see TN domain manager
box in Figure A.8.1 in [10]).

•       It is quoted that “3GPP identifies each E2E network slice using an
integer called S-NSSAI”. Charging for Network Slicing in 3GPP is based on the
use of S-NSSAI and specified in TS 28.201 [6] and TS 28.202 [7]. SA5 would like
to clarify that S-NSSAI is not an integer, but a specific type consisting of an
Integer (SST) and 3-octet String (SD); for further information, see clause 28.4
of 3GPP TS 23.003 [3], and clause 5.4.4.2 of 3GPP TS 29.571 [4]. SA5 would also
like to note that the example values for S-NSSAI in the document [1] (e.g.,
01111111) do not comply with the S-NSSAI format defined by 3GPP.

•       It is quoted that “Note that 3GPP uses the terms NSI and NSSI which are
a set of network function and required resources (e.g. compute, storage and
networking resources) which corresponds to network slice Instance […]”. SA5
would like to clarify the following:

       o        NSI and NSSI are terms introduced in 3GPP TS 28.531 [8]. These
       terms are used interchangeably with NetworkSlice instance (i.e., managed
       object instance of NetworkSlice IOC) and NetworkSliceSubnet instance
       (i.e., managed object instance of NetworkSliceSubnet IOC) respectively,
       as defined in TS 28.530 [8]. An NSI/NSSI is uniquely identified by a SA5
       defined management identifier referred as to Distinguished Name (DN).

       o        The network slice instance defined in 3GPP TS 23.501 [9]
       (uniquely identified by a SA2 defined signalling identifier) can be
       reflected via the NetworkSliceSubnet instance (uniquely identified by an
       DN) and the allocated resources. For further details, see clause 3.1 of
       TS 28.530 [8].

Feedback #4: With regards to 5G E2E Network Slice Mapping Procedure (clause
4.2):

•       In Figure 7, the following annotations are included: “(e.g., 4)”,
“(e.g., 6)” and “(e.g., 1)”. SA5 would like to know whether there is any
description for these numbers in the steps of the figure. .

•       Steps 1, 2, 3, 4 and 5 allocates 3GPP management system functionalities
to NSMF (e.g., receiving requests for network slice instance allocation,
determining the network functions and resources, S-NSSAI assignment, etc).
Since “NSMF” and “NSSMF” are not standardized management functions, SA5
suggests replacing “3GPP NSMF” and “NSSMF” with “3GPP Network Slice Management
Service Provider (NS MnS Provider)” and “3GPP Network Slice Subnet Management
Service Provider (NSS MnS Provider)” respectively, see TS 28.531 [2].

•       Step 6 quotes the following: “3GPP NSMF sends a request to an IETF NSC
(acting as an NSSMF for transport network, from the perspective of the 3GPP
Management System)) for creation of a RFC9543 Network Slice service”. SA5 would
like to note that IETF NSC is not in scope of 3GPP management system. For
coordination with transport network, 3GPP specifies the “Procedure of TN
coordination supporting network slicing” in clause 7.9 of TS 28.531 [1] and the
"Relation between GSMA GST, ServiceProfile and SliceProfile" in normative Annex
L.2 of TS 28.541 [5]. This annex specifies how TN requirements (input to the TN
domain) are derived from TopSliceSubnetProfile.

•       Step 8 quotes the following: “The 3GPP NSMF could maintain the mapping
relationship between S-NSSAI and IETF Network Slice Service ID”. SA5 would like
to clarify that the maintenance of relationship between S-NSSAI and IETF
Network Slice Service ID is a functionality not currently in scope of 3GPP
network slicing management and charging.

Feedback #5: With regards to 5G E2E Network Slice Mapping in Management and
Control Planes (clause 5):

•       It is quoted that “Build up mapping relationship between NSI identifier
and RFC9543 Network Slice Services”: It is unclear what NSI identifier will be
used. SA5 would like to provide the following clarifications:
       o        NSI ID is only for 5GC signaling use, i.e. to identify Core
       Network part of a Network Slice instance when multiple Network Slice
       instances of the same Network Slice are deployed, and there is a need to
       differentiate between them in the 5GC, see clause 3.1 of TS 23.501 [9].
       The NRM attribute cNSIIdList of NRFFunction and NSSFFunction, see TS
       28.541 [5], is a list for NSI ID(s). o        A NetworkSlice instance,
       i.e. a managed object instance of NetworkSlice IOC (see TS 28.541 [5]),
       is uniquely identified by a Distinguished Name (DN).

Feedback #6: With regards to Mapping EP_transport to IETF NS CE Endpoints
(clause 5.1), the document in [1] notes that the translation of EP_Transport
parameters into the corresponding parameters for the CE within the IETF network
slice is not straightforward for certain scenarios. The document quotes the
following: "In these scenarios, additional information are needed to identify
the corresponding CE endpoint for example with other parameters defined in
EP_transport, including: combined identification for NS CE endpoint […], next
hop information […] and QoS profile […]". SA5 would like to clarify the
following:

•       For the combined identification for NS CE endpoint, the following
attributes of EP_Transport IOC  (see clause 6.3.18 in TS 28.541 [5]) can be
used: “localLogicalInterfaceInfo”, which is represented as LogicalInterfaceInfo
<<datatype>> (see clause 6.3.35 of 3GPP TS 28.541[5]), and 
externalEndPointRefList, which is represented as a list of ConnectionPointInfo
<<datatype>> (see clause 6.3.41 of 3GPP TS 28.541[5]).

•       For the next hop information, the attribute “ipAddress” in EP_Transport
IOC attribute can be used for this purpose.

•       For the QoS profile, the attribute “qoSProfile” in EP_Transport IOC
attribute specifies a set of parameters locally provisioned on both sides of
logical transport interface, e.g. DSCP, (see clause 6.4.1 of 3GPP TS 28.541
[5]). In addition, for the SLOs input to the TN domain (TN requirements), SA5
would like to clarify that these are derived from TopSliceSubnetProfile, as
specified in Annex L.2 of TS 28.541 [5].

Feedback #7: With regards to IETF Network Slice request through IETF Network
Slice NBI (clause 7), the document in [1] quotes the following in page 28:
"EP_Transport object class does not define a mechanism for active communication
of EP_RP loopbacks to the IETF ingress PE device (e.g., no PE-CE protocols)".
SA5 would like to clarify that the attribute “routingProtocol” in EP_Transport
can be used for this purpose.

References

[1]    
https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-network-slice-application
[2]     3GPP TS 28.531, “Management and Orchestration; Provisioning”, v19.2.0
[3]     3GPP TS 23.003, “Technical Specification Group Core Network and
Terminals; Numbering, addressing and identification”; v19.3.0. [4]     3GPP TS
29.571, “5G System; Common Data Types for Service Based Interfaces; Stage 3,
(Release 19)”, v19.4.0 [5]     3GPP TS 28.541, “Management and Orchestration;
5G Network Resource Model (NRM); Stage 2 and 3”, v19.5.0 [6]     3GPP TS
28.201, "Charging management; Network slice performance and analytics charging
in the 5G System (5GS); Stage 2", v19.2.0 [7]     3GPP TS 28.202, "Charging
management; Network slice management charging in the 5G System (5GS); Stage 2",
v19.0.0. [8]     3GPP TS 28.530, "Management and orchestration; Concepts, use
cases and requirements", v19.0.0 [9]     3GPP TS 23.501, "System architecture
for the 5G System (5GS)", v19.5.0. [10]    3GPP TS 28.533, "Management and
orchestration; Architecture framework", v19.3.0. [11]    IETF RFC9543, "a
Framework for Network Slices in Networks Built from IETF Technologies".

2. Actions:

To IETF TEAS WG:
Action: TSG SA kindly ask IETF TEAS WG to take the feedbacks above into account.

3. Date of Next SA Meetings:

TSG SA Meeting #111             10th – 13rd Mar 2026                   
Fukuoka, JP TSG SA Meeting #112             9th – 12nd Jun 2026                
    Singapore , SG