Re: [3gpp-ietf-coord] [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Ivo, for the clarification. We will assume then that the review was individual and will not enter it as a liaison statement.

Regards

-éric

From: Ivo Sedlacek <ivo.sedlacek=[e-mail]>
Date: Tuesday, 6 December 2022 at 10:16
To: Eric Vyncke <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: lp-wan <[e-mail]>, Lars Eggert <[e-mail]>, "[e-mail]" <[e-mail]>, Edgar Ramos <[e-mail]>, Gonzalo Camarillo <[e-mail]>
Subject: RE: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Hello,

thank you for your mail.

I am happy to take part in discussion with authors on my comments, and review update draft, if and when produced.

> May the IETF assume that your email is the 3GPP answer to the liaison statement referred in your email ? If so, then I will enter your email reply into the IETF list of liaison statements https://datatracker.ietf.org/liaison/

The review was provided on my own behalf. I do not speak on behalf of entire 3GPP.

Kind regards

Ivo

From: Eric Vyncke (evyncke) <evyncke=[e-mail]>
Sent: pondělí 5. prosince 2022 17:18
To: Ivo Sedlacek <[e-mail]>; [e-mail]; [e-mail]
Cc: lp-wan <[e-mail]>; Lars Eggert <[e-mail]>; [e-mail]; Edgar Ramos <[e-mail]>; Gonzalo Camarillo <[e-mail]>
Subject: Re: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

[Adding LP-WAN WG mailing list as well as the 3GPP-IETF coordination list]

Ivo,

Thank you very much for your valuable review: I am sure that the authors will update their documents based on your detailed review and they will let you know.

May the IETF assume that your email is the 3GPP answer to the liaison statement referred in your email ? If so, then I will enter your email reply into the IETF list of liaison statements https://datatracker.ietf.org/liaison/

Once again, thank you

Regards

-éric

From: last-call <[e-mail]<mailto:[e-mail]>> on behalf of Ivo Sedlacek <ivo.sedlacek=[e-mail]<mailto:ivo.sedlacek=[e-mail]>>
Date: Monday, 5 December 2022 at 16:41
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Last-Call] Review of draft-ietf-lpwan-schc-over-nbiot-13

Hello,

3GPP TSG CT WG 1 received an liaison statement (LS) https://3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_138e/Docs/C1-226012.zip<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-f4faa101d0a8634e&q=1&e=95d62817-daf6-450a-afde-855d59d66acc&u=https%3A%2F%2F3gpp.org%2Fftp%2Ftsg_ct%2FWG1_mm-cc-sm_ex-CN1%2FTSGC1_138e%2FDocs%2FC1-226012.zip> from IETF LPWAN working group, requesting comments on draft-ietf-lpwan-schc-over-nbiot.

I am working in 3GPP CT1 on behalf of Ericsson.

My comments to https://www.ietf.org/archive/id/draft-ietf-lpwan-schc-over-nbiot-13.txt are below.


COMMENT-1:

section 3 "   *  HSS.  Home Subscriber Server.  It is a database that performs

      mobility management.
"  -> HSS contains subscription data for users. While HSS contains in the subscription data some information needed for mobility management, the mobility management itself is performed by MME based on subscription data from the HSS.

Proposal:
-------------

*  HSS.  Home Subscriber Server.  It is a database that contains users' subscription data, including data needed for mobility management.
-------------


COMMENT-2:

section 3 "   *  NGW-PGW.  Network Gateway - Packet Data Node Gateway.  An

      interface between the internal with the external network.

" -> P-GW is abbreviation for "PDN Gateway" (see 3GPP TS 24.301) and "PDN" is abbreviation for "Packet Data Network" (see 3GPP TR 21.905). So, text should refer to "Packet Data Network Gateway" (rather than Packet Data Node Gateway"). This comment also applies other places in the document.


Proposal:
-------------

   *  NGW-PGW.  Network Gateway - Packet Data Network Gateway.  An interface between the internal with the external network.
-------------
and "Packet Data Network Gateway" should be used instead of "Packet Data Node Gateway" anywhere in the draft.



COMMENT-3:

section 4 "   Figure 1 shows this architecture, where the Network Gateway Cellular
   Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co-
   locating entities in different paths.  For example, a Dev-UE using
   the path formed by the Network Gateway Mobility Management Entity
   (NGW-MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway
   (NGW-PGW) may get a limited bandwidth transmission from a few bytes/s
   to one thousand bytes/s only.

" - figure 1 does not show NGW-CSGN. Figure 1 only shows the Dev-UEs, RGW-eNB, NGW-MME, NGW-CSGW, HSS, NGW-SCEF, NGW-PGW, and application server.

                   If the intention of NGW-CSGN is to include all those entities, then it should be stated - in section 3, section 4 or both.

                   If the intention of NGW-CSGN is to include some of those entities (e.g. all except Dev-UEs and AS), then it should be stated too - in section 3, section 4 or both.



COMMENT-4:

section 4 "The Open Mobile Alliance (OMA)

   [TS23222] and the One Machine to Machine (OneM2M) [TR-0024] define

   the northbound APIs [TR33203]."

- 3GPP TS 23.222 is a 3GPP document (rather than OMA document) so the reference name "[TS23222]" seems misleading.

- 3GPP TS 33.203 is a TS rather than TR. Moreover, 3GPP TS 33.203 is a document for IP Multimedia subsystem and its relationship to LPWAN is not clear.



Proposal:

- for TS 23.222 - either replace it with OMA documents defining northbound APIs, or refer to 3GPP for TS 23.222.

- for TS 33.203 - replace with correct TS number for northbound APIs. Likely TS 33.122 is meant.


COMMENT-5:

section 5 "   3GPP standardizes NB-IoT and, in general, the cellular technologies

   interfaces and functions.  Therefore, the introduction of SCHC

   entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in

   the NB-IoT standard, which implies that the standard specifying SCHC

   support would not be backward compatible.

" -> statement "the standard specifying SCHC support would not be backward compatible" is not necessarily true. It depends on method selected for introduction of SCHC - e.g. if support of SCHC is negotiated before SCHC usage, introduction of SCHC can be backward  compatible.



Proposal: remove text ", which implies that the standard specifying SCHC

   support would not be backward compatible"



COMMENT-6:

section 5 "The radio network transmits the

   packets as non-IP traffic using IP tunneling or SCEF services.

" - it is not clear what is meant by "radio network".

If "radio network" means RGW-eNB (acting towards NGW-MME or NGW-CSGW), then this is not correct as RGW-eNB communicates with NGW-MME or NGW-CSGW (and not SCEF).

If "radio network" means entire 3GPP network (except application server) acting towards application server, then this would be correct.



Proposal: "NGW-PGW or NGW-SCEF transmit the packets which are non-IP traffic, using IP tunneling or API calls."



COMMENT-7:

section 5.1.1 "The packets can be delivered using IP-tunnels to the 3GPP network or

   NGW-SCEF functions (i.e., API calls).

" - the above is not very clear:

- if this refers to packet exchange between NGW-PGW and Application Server or NGW-SCEF and Application Server, fine.

- If this refers to packets exchanged between Dev-UE and Application Server, this is not completely correct - non-IP data PDU is transported between Dev-UE and RGW-eNB without IP tunnel.



Proposal: "The packets can be delivered between the NGW-PGW and the Application Server or between the NGW-SCEF and the Application Server, using IP-tunnels or API calls.".



COMMENT-8:

section 5.1.1.2 "A global service assigns a QoS to the packets depending on the

   billing.

" - while this is possible, QoS can be assigned due to other reasons too.



Proposal: "A global service assigns a QoS to the packets e.g. depending on the billing."



COMMENT-9:

section 5.2.2 "No-Access Stratum (NAS)" - "NAS" stands for "Non-Access Stratum" (see 3GPP TR 21.905). This comment also applies to other places in the document.



Proposal: "replace "No-Access Stratum (NAS)" with "Non-Access Stratum (NAS)" anywhere in the draft



COMMENT-10:.

- section 5.2.2.1 "S1-lite" - "S1-lite" does not seem to be defined in any of TS 23.401. TS 36.300 or TS 36.413. Please add a reference for 3GPP specification or use S1.



COMMENT-11:

appendix B "NAS packets are encapsulated within an RRC (Radio

   Resource Control) TGPP36331 message.

" -> not clear what "TGPP36331" is. Likely, this should be a reference to 3GPP TS 36.331.



Proposal: "NAS packets are encapsulated within an RRC (Radio Resource Control) (see [TGPP36331]) message." and add a reference to TS 36.331 in section 9.



Kind regards



Ivo