|
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 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
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
