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

[Ana Minaburo <[e-mail]>]

Dear Ivo,

Thank you very much for your valuable inputs. Please find below our comments
A new version of the draft will be published with your comments.

Ana

On Tue, Dec 6, 2022 at 12:51 PM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> 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]> on behalf of Ivo Sedlacek <
> ivo.sedlacek=[e-mail]>
> *Date: *Monday, 5 December 2022 at 16:41
> *To: *"[e-mail]" <[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.
>
> -------------
>

[Ana] Done. I've changed it.

>
>
> 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.
>
[Ana] Done.

>
>
> 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.
>
>
[Ana] Neither one nor the other, the only intention was to simplify the
architecture to give the most important elements. I've changed fig1 and I
added the NGW-CSGN which involves the NGW-MME and NGW-CSGW

>
>
> 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.
>
>
[Ana] As I used the OMA document, I will put OMA's Reference.


> - for TS 33.203 - replace with correct TS number for northbound APIs. Likely TS 33.122 is meant.
>
>
[Ana] I've  changed it.

>
>
> 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"
>
> [Ana] Done

>
>
> 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."
>
>
[Ana] Done

>
>
> 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.".
>
> [Ana] Done

>
>
>

> 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."
>
> [Ana] Done

>
>
> 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
>
> [Ana] Done

>
>
> 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.
>
> [Ana] I kept 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.
>
> [Ana] Good Catch! I've put the Reference

>
>
> 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.
>
>
[Ana] Done

>
>
> Kind regards
>
>
>
> Ivo
>
>