90% of what happens in standards consists of extraordinary engineers working together in good faith. In this 3GPP email exchange, Bruno Landis of Nokia, Frank Yong Yang of Ericsson, Caixia Qi of Huawei, and Li Zhijun of ZTE exchanged ideas and worked out one of the hundreds of issues not yet decided for 5G.
This is from an open mailing list of the 3GPP standards group. As you can see, the tone is respectful as they try to get things right. This corresponds to my experience in standards. Honest folk, working hard to move the industry forward.
The exchange is also interesting because it shows how complicated even seemingly minor 5G questions can be. I’m writing a book on 5G and wouldn’t understand most of the below with help from an expert.
Any error could have practical complications. Some might be minor, like a call drop when you go from France to Germany. Others can be more severe. In the last few years in the US, the 9-1-1 emergency system has failed several times. (I don’t know if better standards could have prevented that.)
There are a few issues that may be very political. That’s the main reason companies like these spend enormous amounts to send dozens of people to meetings like these. Most questions are like this, with little or no advantage to one company or another.
The choice of DMT VDSL standards cost the QAM proponents hundreds of millions. Qualcomm has raised its royalty rates by more than a billion dollars a year after pushing its software through 3GPP.
But most of the work is like this: good engineers working together.
URLLC stands for “Ultra Reliable Low Latency Communications.” It’s designed to bring the “air latency” (between your device and the cell tower) to under 5 ms. It’s an important part of the future 3GPP release 16.
“Ultra Reliable” is at best unproven and possibly just a lie. 5G fixes a number of known problems in 4G, but new problems are sure to emerge in 5G. In particular, large networks will many millions of possibly vulnerable points, from Edge servers to IoT devices. Respected Professor Gerhard Fettweis has said 5G might not be secure enough to control autonomous cars, which have many issues.
QoS – quality of service – has long been an unfulfilled promise of cellular networks. Columbia Professor Henning Schulzrinne has pointed out that QoS in 3G networks was expected to solve many problems. It didn’t. That experience was repeated in 4G. Henning this spring believed it is too early to be confident of better results in 5G.
QoS has a fancy new name, “Network Slicing.” It’s years away from proven performance.
Subject: Re: URLLC – Comments to C4-195221 to 5224
Dear Caixia,
thanks for the revisions that look very good to me.
Best regards,
Bruno
Subject: Re: URLLC – Comments to C4-195221 to 5224
Dear Bruno and Frank,
I update the contributions based on the comments from Bruno, and upload on to the server as the attachment.
Giorgi will help to present the papers, and we can revise the papers based on the discussion on the STOP bit and Session Reporting Trigger issues.
Have a safe trip to Reno, and all the best during the next meeting.
BR.
Caixia Qi
Huawei Technologies Co., Ltd.
http://www.huawei.com<http://www.huawei.com/>
Dear Caixia, Frank,
thanks for the draft revisions which look good. A few comments:
* I don’t understand the need for/don’t agree with a new STOP bit in the Requested QoS Monitoring IE (cf Frank’s comment). The SMF can remove the SRR if QoS monitoring is no longer needed.
* I would prefer clauses 5.2.x.2.a and 5.2.x.3.a to be specified in clause 5.24.x (Per QoS Flow Per UE QoS Monitoring), i.e. 5.24.x would be structured as:
* 5.24.x.1 General (-> contents of your other CR)
* 5.24.x.2 QoS Monitoring Control
* 5.24.x.3 QoS Monitoring Reporting
(a similar structure is proposed for ATSSS and TSN, where all reqts are captured in dedicated ATSSS and TSN clauses)
* I agree to discuss next week whether to keep or not a Session Reporting Trigger in the SSR. I don’t see a pb with this IE, and actually this allows to dedicate the SRR to a specific functionality. Let’s say that this comment does not relate to your CR, and we will align the CRs next week if necessary based on what we conclude on the SRR CR.
* 5.2.x.3.a: 2nd paragraph: I recommend to split the sentence “or the time generating …”: the text does not read so well. Also what is the trigger for sending a “failure” report, is it that no timestamp is received in UL packet for a delay exceeding the Packet Delay Threshold, or exceeding the “Measurement Period”, or both (depending on whether the reporting is event triggered or periodic)? Very last sentence of this paragraph has descriptive text instead of normative text (“sends”).
thanks
Best regards,
Bruno
Subject: Re: URLLC – Comments to C4-195221 to 5224
Dear Frank,
Thanks for checking and the comments.
I have updated the contribution according to most of your comments, except for the Session Report Trigger, it is related to the base on CR#0322, I will update this paper based on the agreement on CR#0322.
BR.
Caixia Qi
Huawei Technologies Co., Ltd.
http://www.huawei.com<http://www.huawei.com/>
Dear Caixia,
Thanks for the revision.
I don’t agree to introduce this Session Report Trigger. I think it is sufficient to have QoS Monitoring per QoS flow control Information:
QoS Monitoring per QoS flow control Information
C
This IE shall be present if the per QoS Flow per UE QoS monitoring reporting is triggered.
Several IEs within the same IE type may be present to represent a list of QoS Monitoring per QoS flow control Information.
–
–
–
X
QoS Monitoring per QoS flow control Information
With this way, each session related reports, e.g. QoS monitoring for QoS flow, Access availability, are completely separated; in fact those reports are complete different has no synergy. (this is different from the Usage Report Trigger)
And in your new chapter, 5.2.x.3.a Reporting of QoS Monitoring Report –> title may be reworded e.g. “as Control of QoS Monitoring Report” …just not reporting and report.
You should reflect use of QoS Monitoring per QoS flow control information, and also list the IE included, e.g. one or more QoS flows, and behaviour of UPF, e.g. select one or more packets pertaining to the requested QoS flow, insert the time stamp…
Within QoS Monitoring Control information, we need a mechanism to stop the QoS monitoring…not only when the SRR is removed. Probably we can use “Requested QoS Monitoring”, a bit to indicate “stop”.
Dear Bruno and Frank,
Based on your comments, I have merged the URLLC contributions into one, and use the new defined rule SRR to support the QoS monitoring function.
Please check whether I capture all of your comments.
And one issue is related to the mechanism on measurement failure, Bruno has some comments, current proposal is if the UPF sending out the downlink packet used for QoS monitoring, and during the packet delay thresholds, if no uplink packet received from the RAN used for QoS monitoring, the UPF shall report the QoS monitoring measurement failure to the SMF. That’s why there has some description in the rule provision and monitoring result reporting.
主题: RE: URLLC – Comments to C4-195221 to 5224
Dear Frank, Caixia,
I agree that both models/approaches (using URR associated to PDRs, or using the new Session Reporting Rule defined in C4-105014 with examples of use in C4-195048 and C4-195245 not linked to any PDR) can work, and also agree that using the URR for QoS monitoring is somehow mis-using & overloading the URR (by the way, it also uses it partially only, only for triggering the measurement, not for reporting the QoS results – which is also not so nice).
So I also think that using the new SRR with QoS Monitoring Control Information in the new Create/Update SRR IE would be cleaner protocol wise. We don’t need any change to the PDR nor even to the QER with this approach. The QoS Monitoring Control Info contains the QFI(s) to be monitoring.
A few other differences between the two solutions:
* With URR, every UL/DL PDRs of QoS flows to monitor are associated to URR
* With SRR:
* UPF would derive from the QFIs to monitor the DL PDRs (of any SDFs) associated to a QER with a matching QFI and add the timestamp to some of the DL packets of the corresponding DL FAR (SMF would not control the exact SDF to use for inserting the timestamp – UPF would choose any SDF matching the QFI, but this should be fine).
* UPF does not get an indication of the UL PDRs for which timestamp info may be received from RAN. But I assume there is no need for such info in the UPF.
I would recommend adopting the new SRR for QoS monitoring (which would require to revise the CR agreed at last CT4 meeting).
Best regards,
Bruno
From:
Subject: RE: URLLC – Comments to C4-195221 to 5224
Dear Caixia, Bruno,
Regarding to
“Caixia: Support the QoS monitoring based on URR is agreed also in stage2, the reason updating the Measurement Method and Usage reporting trigger is the mandatory IE, anyhow shall be included.”
I think using URR would work, but I prefer to use new type rule or simply with a new IE at message level to provide same level control, since QoS monitoring measurement for QoS flow(s) is complete different from the original intention of URR.
URR, as of today, is for charging and policy control, and it is to control the measurement on volume/time/event for user plane DATA.
5.2.2.1 General
The CP function shall provision URR(s) for a PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to:
– measure the network resources usage in terms of traffic data volume, duration (i.e. time) and/or events, according to the provisioned Measurement Method; and
– send a usage report to the CP function, when the measurement reaches a certain threshold, periodically or when detecting a certain event, according to the provisioned Reporting Triggers or when an immediate report is requested within an PFCP Session Modification Request.
NOTE: The UP function sends a usage report without performing network resources usage measurements when being requested to detect and report the the start of an SDF or application traffic.
Yes, Measurement Method is Mandatory IE, but it could be included but set with 0, basically means no measurement (I have a CR C4-195114 clarify this); and use QoS Monitoring Control information to tell what to do with this URR, this separates QoS monitoring from the rest URR.
I think URR is already complex enough, we should not overload it.
Regards
Frank
Subject: Re: URLLC – Comments to C4-195221 to 5224
Dear Bruno and Frank,
Thanks for all the detailed comments and the revisions.
I will combine the related contributions into one, and may be easy to discuss.
And please find my reply as below.
发送时间: 2019年11月6日 21:18
收件人: Landais, Bruno (Nokia – FR/Lannion)
主题: RE: URLLC – Comments to C4-195221 to 5224
Dear Bruno, Caixia,
Thanks for the revisions, will review.
Just replying your comments and clarify my comment as below.
Regards
Frank
From:
Subject: RE: URLLC – Comments to C4-195221 to 5224
Dear Caixia, Frank, all,
Please find attached my comments and proposed updates to the following CRs:
the extension proposed in the FAR implies that different FARs would need to be provisioned if not all QoS flows of the PDU session are subject to QoS monitoring. Shouldn’t such indication be set instead in a QER (together with the QFI) ?
Caixia: Fine to define in the QER, to avoid the different FARs, as the QoS monitoring is applied for some packets in the service flow.
“if the QoS monitoring is applied for this packet”: I assume that not all GTP-U packets will include timestamp information. So the text is a bit confusing.
Caixia: Your assumption is correct, will update.
The description of the procedure in clause 5.24.x Per QoS Flow Per UE QoS Monitoring (C4-194513 agreed at last meeting) should be updated accordingly.
Caixia: Will update the paper this meeting.
I also add comments/questions below (BL>).
Caixia: Thank you, I will make revision.
Best regards,
Bruno
Subject: RE: URLLC – Enable QoS Monitoring in PDR (C4-195221)
Dear Caixia,
Thanks for the URLLC CRs.
,
I have a couple of initial comments/questions:
* A general comments: these CRs should have dependency to SA2 CR S2-1910088 23.501CR1716; and a minor one, it could be better if you can combine those CRs together since they are tightly related or given some hint for reader in the other comment field;
* I agree with Bruno, it seems no need to have QoS Monitoring Packet indicator in the PDR. As already agreed in C4-194513, where it reads “The SMF shall provision one or more URRs to instruct the UPF to monitor the QoS of QoS flows and associate them to the DL and UL PDRs of the QoS flows that need to be monitored. The UPF shall report the QoS monitoring result of the QoS flows to the SMF.”, so together with the QoS Monitoring per QoS flow control Information IE you added in URR give sufficient information to UPF to start QoS Monitoring;
* On the other hand, I am thinking whether we can directly provide QFIs in the URR to be monitored (in QOS monitoring control information) (which using PDRs at all), so that, the UP find service data flows pertaining to the required QoS flow to perform QoS monitoring? And in such case, in the PDR, CP could use QoS Monitoring Packet indicator in the PDR to tell UP to use this service data flow to perform QoS monitoring, instead UP look for Service Data flow with that QFI on its own;
BL> trying to understand the suggestion in the very last paragraph:
* do you suggest we would no longer associate the URR with PDR (i.e. use a Session Reporting Rule and NOT a URR), or that the QFI in URR would be provisioned in addition to associating the URR with the PDRs? In the latter case, can you please clarify the benefit.
Frank: As you also indicated “I assume that not all GTP-U packets will include timestamp information”, I am thinking to use your new rule – Session Reporting Rule, which is preferred.
Regarding to your Session Reporting Rule, I think it is a good idea in general. But I think it would be good to NOT have a reporting trigger in the rule level, instead we can add something called Session Reporting Control Information (group IE), which contains e.g. QoS Monitoring Control Information, ATSSS reporting control information (access availability).
Then in the QoS monitoring control information, it provides QoS flows to monitoring. (PDR is associated with QER, so UP knows which Service flows are associated with the requested QFIs), thresholds, event, triggers…
the UPF just need perform QoS Monitoring accordingly, i.e. find service data flows with requested QFIs, insert timestamp, perform measurement.
With this approach, it separates features completely.
The wording “at least 1 bit shall be set to “1” makes some problems. With using QoS monitoring control information in a new rule, no need change Measurement Method and Usage reporting trigger. I even think there is no need change in FAR, for outer header creation.
Caixia: Support the QoS monitoring based on URR is agreed also in stage2, the reason updating the Measurement Method and Usage reporting trigger is the mandatory IE, anyhow shall be included.
* new QMP indicator cannot be added in PDR to say “use this service data flow to perform QoS monitoring”. PDR is about traffic pattern to match. Not about how to process the traffic matching the pattern. There is no QMP indicator for traffic coming from N6 for instance.
* For C4-195222, I have a question, are we assuming those QoS flow eligible for QoS Monitoring are required to have a separated FAR? If so, the note could also be enhanced, maybe we can consider, e.g. ” NOTE x: The UPF may select one or more service data flow packets pertaining the QoS Flow to be monitored when available, otherwise generate one or more dummy packets for QoS monitoring, and then shall include the time stamp in the PDU Session Container extension header of the G-PDU which is to convey those packets. (See also clause xxx in 3GPP TS 38.415 [34].” –> Alternatively, we should add some text in your C4-194513, 5.24.x Per QoS Flow Per UE QoS Monitoring;
BL> see my comments above (this flag could be set in QER rather than FAR).
Caixia: Ok to define in the QER, to avoid the different FARs, as the QoS monitoring is applied for some packets in the service flow.
* For C4-195223:
* I think we need not impact Measurement Method and Reporting Trigger, all these information elements can be defined in QOS monitoring control information. Note in C4-195224, you have no usage report trigger defined.
BL> I think it is better to have a new “delay” measurement method.
* Can all three bits be set to “1”, to me, it seems also fine. If so the sentence “The bits of EVETT and SESR may be set to 1 simultaneously, the bits PERO and SESR may also be set to 1 simultaneously.” Can be removed.
BL> yes, I have the same comment
Caixia: Agree with you, I will remove the sentence.
* For C4-195224:
* I think the description in 5.2.2.3.a contains errors, e.g. QoS Monitoring measurement is not like measurement on the usage, there is no “reapply” threshold, shall reset its ongoing measurements for the URR that is removed;
Caixia: Will update the wording.
* Are you intending to create a URR for QoS monitoring per QoS flow?
BL> it shall be possible to provision one URR for multiple QoS flows.
Caixia: Same understanding as Bruno.
* “Bit 4 – PLMF (Packet Delay Measurement Failure): If this bit is set to “1”, this indicates no uplink packet used for QoS monitoring is received, and the packet delay is exceeded.”, when this happens, there is no measurement report? i.e. UL/DL Delay and RTT are not present?
Caixia: Yes, no measurement is reported, as no uplink packet is received, the UPF cannot measure the delay.
Regards
Frank
Subject: URLLC – Enable QoS Monitoring in PDR (C4-195221)
Dear Caixia,
thanks for your input CRs. I am just starting to review them, and have a first question for clarification on the following CR (and related stage 2 change).
C4-195221
Enable QoS Monitoring in PDR
Huawei, China Telecom
6.1.13
Rel-16
QoS monitoring is enabled by associating a URR (for QoS monitoring) to the UL/DL PDRs corresponding to the QoS flows to be monitored (per your CR agreed at the last CT4 meeting).
So what is the purpose of defining a new QoS Monitoring Packet Indicator in PDR? Which specific packet processing (i.e. FAR, URR, QER) do you intend to control over N4 / apply to packets matching such a PDR, i.e. to the “QoS monitoring packets” (which I understand can be regular UL GTP-U packets or UL dummy GTP-U packets)? this is not specified anywhere in the CR. The reason for change on the cover page says: “Based on the indicator, UPF shall retrieve the timestamp/packet delay related information included in the GTP-U PDU session container extension header”, but I don’t think we need any new PFCP extension to instruct the UPF to extract the timestamp/delay information – the UPF PSA will do so, as part of removing the entire GTP-U header (and entire PDU Session Container). Likewise, the UPF PSA can drop UL dummy packets, w/o the need for any specific N4 rule for this.
The definition of the QoS Monitoring Packet Indicator in clause 8.2.y is not clear to me either: “It indicates if per QoS Flow per UE level QoS monitoring applies for the UL”. Whether QoS monitoring applies to UL is known by the association of URR to the UL PDRs. So here the indicator seems to be to “indicate if an UL GTP-U packet carries timestamp information for QoS monitoring”?
It seems to me that we don’t need the changes of this CR. Can you please clarify.
thanks
Best regards,
Bruno
From:
Subject: C4-195221,C4-195222,C4-195223,C4-195224 on URLLC
Dear Bruno, Frank, Jones and Zhijun,
As you know, I am not able to attend the Reno meeting, could you please check the couple of contributions from Huawei on URLLC, and provide comments if any.
It is better if I can make the revisions according to your comments before the meeting.
BR.
Caixia Qi
Huawei Technologies Co., Ltd.
http://www.huawei.com<http://www.huawei.com/>