Internet DRAFT - draft-aguilar-schc-convergence

draft-aguilar-schc-convergence







schc Working Group                                            S. Aguilar
Internet-Draft                                                  C. Gomez
Intended status: Standards Track                                R. Vidal
Expires: 12 November 2023           Universitat Politecnica de Catalunya
                                                             11 May 2023


                        SCHC Convergence Profile
                   draft-aguilar-schc-convergence-00

Abstract

   The present document defines a profile of Static Context Header
   Compression and fragmentation (SCHC) [RFC8724] for multi-radio
   devices or multi-network application.  This profile can be used
   simultaneously over LoRaWAN, Sigfox, NB-IoT and any other technology
   that may use SCHC Fragmentation/Reassembly functionality.


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 12 November 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Aguilar, et al.         Expires 12 November 2023                [Page 1]

Internet-Draft              SCHC Convergence                    May 2023


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation and Use Cases  . . . . . . . . . . . . . . . . . .   3
     3.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  SCHC over All Profile . . . . . . . . . . . . . . . . . . . .   4
     4.1.  SCHC over All Architecture  . . . . . . . . . . . . . . .   4
     4.2.  Single SCHC ID  . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Uplink Fragmentation  . . . . . . . . . . . . . . . . . .   7
       4.3.1.  Uplink ACK-on-Error Mode: Two-byte SCHC Header  . . .   8
       4.3.2.  Downlink Consideration in Uplink Fragmentation  . . .   9
     4.4.  Rule Management . . . . . . . . . . . . . . . . . . . . .   9
     4.5.  SCHC over All F/R Message Formats . . . . . . . . . . . .   9
       4.5.1.  Regular SCHC Fragment . . . . . . . . . . . . . . . .   9
       4.5.2.  All-1 SCHC Fragment . . . . . . . . . . . . . . . . .  10
       4.5.3.  SCHC ACK Format . . . . . . . . . . . . . . . . . . .  10
       4.5.4.  SCHC Receiver-Abort Message . . . . . . . . . . . . .  10
       4.5.5.  SCHC Sender-Abort Messages  . . . . . . . . . . . . .  11
       4.5.6.  SCHC ACK Request  . . . . . . . . . . . . . . . . . .  11
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The Static Context Header Compression and fragmentation (SCHC)
   specification [RFC8724] provides generic adaptation layer
   functionality, including Compression/Decompression (C/D) and
   Fragmentation and Reassembly (F/R) functionality.  The latter offers
   three different modes, providing different features.

   SCHC over LoRaWAN [RFC9011], SCHC over Sigfox
   [I-D.lpwan-schc-over-sigfox] and SCHC over NB-IoT
   [I-D.lpwan-schc-over-nbiot] are technology-specific SCHC profiles,
   which provide an optimal configuration of SCHC over the corresponding
   technologies.  However, the F/R functionalities of these profiles are
   not compatible.  Therefore, multi-radio devices (e.g., supporting



Aguilar, et al.         Expires 12 November 2023                [Page 2]

Internet-Draft              SCHC Convergence                    May 2023


   LoRaWAN, Sigfox and NB-IoT interfaces on the same device) require
   multiple implementations of the SCHC F/R sublayer, one for each
   technology.

   Moreover, multi-network solutions, where the same application is
   deployed over different LPWAN technologies also require multiple
   implementations of the SCHC F/R sublayer, one for each deployment.

   To reduce implementation complexity, and enable a single convergent
   F/R sublayer, this document provides the F/R details for a SCHC
   profile that can be used over all the LPWAN technologies overviewed
   in [RFC8376], leveraging the benefits of the Compound ACK.  This
   profile can also be used over other technologies that may use SCHC
   Fragmentation/Reassembly functionality.


2.  Terminology

   It is assumed that the reader is familiar with the terms and
   mechanisms defined in [RFC8376] and in [RFC8724].

3.  Motivation and Use Cases

3.1.  Motivation

   IoT applications running over LPWAN devices are tied up to the
   selected LPWAN technology.  The LPWAN constrains influence the design
   of the IoT application itself.  This presents problems when migrating
   to other LPWANs or networks, as it may imply redesigning the complete
   IoT application (from device code to backend code).  The LPWAN, as a
   Layer 2 (L2), should be transparent to IoT application (and
   developers), as it is in the IP domain.

   Current advances in the adoption of IPv6 over LPWAN achieved
   interoperability for application thanks to SCHC [RFC8724], and a
   single SCHC C/D sublayer.  However, each LPWAN technology requires a
   different implementation of the SCHC F/R sublayer, with different
   (but actually very similar) F/R modes.  Therefore, an IoT application
   using multiple LPWANs (multiple radios o multiple networks) will
   require multiple SCHC F/R implementation in device and backend code.
   This is not the case for the C/D sublayer.

   To reduce code complexity and maintenance, and achieve a single
   convergent SCHC F/R sublayer, this document provides a SCHC Profile
   which considers the singularities of LoRaWAN, Sigfox and NB-IoT,
   while providing general F/R modes that work over all of these
   technologies simultaneously.




Aguilar, et al.         Expires 12 November 2023                [Page 3]

Internet-Draft              SCHC Convergence                    May 2023


3.2.  Use Cases

   The SCHC over All profile has several use cases:

   *  Generic SCHC F/R Profile for implementation of SCHC to test over a
      new technology.  SCHC out-of-the-box F/R modes.

   *  Multi-radio devices: Devices implementing more than one LPWAN
      radio.

   *  Multi-network applications: Applications deployed over more than
      one LPWAN.

   *  Network Redundancy:

      -  Devices using another LPWAN as backup,

      -  devices sending the same SCHC Fragment in different networks to
         increase the probability of successful fragmented packet
         reception.

   *  Increased device duty-cycle as more networks are available, e.g.,
      if SCHC Packet transmission is not possible over LoRaWAN due to
      duty-cycle restriction, SCHC Packet transmission may be performed
      over Sigfox or NB-IoT.  This applies also for SCHC Fragments.

   *  Devices sending SCHC Fragments over different LPWANs to check
      available coverage.

4.  SCHC over All Profile

4.1.  SCHC over All Architecture

   [RFC8376] overviews the LoRaWAN, Sigfox, and NB-IoT protocols and
   their network architectures.  More specifically, [RFC9011] maps the
   network architecture entities between LoRaWAN and LPWAN, as described
   in [RFC8724].  Similarly, [I-D.lpwan-schc-over-sigfox] and
   [I-D.lpwan-schc-over-nbiot] for Sigfox and NB-IoT performs the same
   mapping for Sigfox and NB-IoT, respectively.

   Figure 1 shows the architecture when using several SCHC F/R
   implementations, one for each LPWAN technology.  In this case, it is
   possible to send SCHC Packets over different LPWAN networks.








Aguilar, et al.         Expires 12 November 2023                [Page 4]

Internet-Draft              SCHC Convergence                    May 2023


 ()   ()   ()       |  |
  ()  () () ()     / \/ \     +---------+   +---------+
 () () () () ()   / / \  \====| Network |===|SCHC over|===
  ()  () () ()                | Gateway |   |  NB-IoT | ||
 () () () () ()               | (NB-IoT)|   +---------+ ||
  ()  () () ()                +---------+               ||
  () () () ()                                           || +-----------+
 ()   ()   ()       |  |                                || |Application|
  ()  () () ()     / \/ \     +---------+   +---------+ || +-----------+
 () () () () ()   / / \  \====| Network |===|SCHC over|====|  SCHC C/D |
  ()  () () ()                |   Core  |   | Sigfox  | || +-----------+
 () () () () ()               | (Sigfox)|   +---------+ ||
  ()  () () ()                +---------+               ||
 () () () ()                                            ||
 ()   ()   ()       |  |      +---------+   +---------+ ||
  ()  () () ()     / \/ \     | Network |   |SCHC over| ||
 () () () ()      / / \  \====| Server  |===| LoRaWAN |===
  ()  () () ()                |(LoRaWAN)|   +---------+
 () () () ()                  +---------+
 End devices  Radio Gateways  Network Server SCHC C/D and F/R
   (devices)        (RGW)         (NGW)

   Figure 1: Architecture when using several SCHC F/R implementations

   Figure 2 presents the SCHC over All architecture, with a single SCHC
   C/D and F/R sublayer.  This architecture provides a single
   implementation of the SCHC F/R sublayer.
























Aguilar, et al.         Expires 12 November 2023                [Page 5]

Internet-Draft              SCHC Convergence                    May 2023


   ()   ()   ()       |  |
    ()  () () ()     / \/ \     +---------+
   () () () () ()   / / \  \====| Network |==========
    ()  () () ()                | Gateway |        ||
   () () () () ()               | (NB-IoT)|        ||
    ()  () () ()                +---------+        ||
 () () () () ()                               +---------+
   ()   ()   ()       |  |                    |SCHC C/D |
    ()  () () ()     / \/ \     +---------+   |---------|  +-----------+
   () () () () ()   / / \  \====| Network |===|SCHC over|==|Application|
    ()  () () ()                |   Core  |   |   All   |  +-----------+
   () () () () ()               | (Sigfox)|   +---------+
    ()  () () ()                +---------+        ||
   () () () ()                                     ||
   ()   ()   ()       |  |                         ||
    ()  () () ()     / \/ \     +---------+        ||
   () () () () ()   / / \  \====| Network |==========
    ()  () () ()                | Server  |
   () () () () ()               |(LoRaWAN)|
    ()  () () ()                +---------+
   End devices   Radio Gateways  Network Server SCHC C/D and F/R
    (devices)        (RGW)         (NGW)            Server

                 Figure 2: SCHC over All architecture

   In the SCHC over All Profile, as devices have a single SCHC F/R
   implementation, F/R RuleIDs are the same, independently of the LPWAN
   technology used, reducing the device memory and complexity
   requirements when compared to multiple SCHC F/R implementation.

4.2.  Single SCHC ID

   To simplify the access to RuleIDs and to converge the different
   device IDs provided by the networks involved, a device needs to have
   a new identifier called the single SCHC ID.

   A device ID translation table maps the network device ID to single
   SCHC ID.  Then, with the single Device ID, it is possible to look up
   the Rules set and identify the corresponding Rules for such device.
   This dissociates the network device ID form the Rules, allowing to
   use the same Rule set for the same device independently of the access
   network.

   The network device IDs used by the LPWAN technologies included in
   this Profile are:

   *  LoRaWAN: DevID




Aguilar, et al.         Expires 12 November 2023                [Page 6]

Internet-Draft              SCHC Convergence                    May 2023


   *  Sigfox: DeviceID

   *  NB-IoT: IMEI

   Figure 3 presents a diagram of the SCHC over All architecture
   including the Single SCHC device ID translation table.

           +-----------+
           |   Table   |==========
           | Device ID |        ||
           |translation|        ||
           +-----------+        ||
                          +---------+
                          |SCHC C/D |
                          +---------+  +-----------+
     (from All LPWANs) ===|SCHC over|==|Application|
                          |   All   |  +-----------+
                          +---------+

         Figure 3: Single SCHC device ID translation table diagram

4.3.  Uplink Fragmentation

   ACK-on-Error mode is RECOMMENDED for the transmission of Uplink SCHC
   Packets that require fragmentation and need to be sent reliably.
   ACK-on-Error mode is optimal, since it leads to a reduced number of
   ACKs in the lower capacity Downlink channel as Downlink messages can
   be sent asynchronously and opportunistically.  Moreover, ACK-on-Error
   mode supports variable MTU (which is critical for changing from one
   LPWAN technology to another when sending SCHC Fragments spread across
   different LPWANs), and out-of-order delivery (in case SCHC Fragments
   are received out-of-order at the SCHC F/R receiver).

   SCHC over LoRaWAN [RFC9011], SCHC over Sigfox
   [I-D.lpwan-schc-over-sigfox] and SCHC over NB-IoT
   [I-D.lpwan-schc-over-nbiot] provide uplink fragmentation SCHC
   profiles.  At the SCHC Fragment level, these profiles are not
   compatible with one another.  However, one of the SCHC over Sigfox
   uplink fragmentation modes (Two-bytes Option 2) has several
   similarities with the ACK-on-Error SCHC over LoRaWAN profile.  Such
   similarities include:

   *  2-byte SCHC Fragmentation Header size.

   *  10-byte tile size.

   *  2-byte Rule ID size.




Aguilar, et al.         Expires 12 November 2023                [Page 7]

Internet-Draft              SCHC Convergence                    May 2023


   *  No DTag

   Differences between the SCHC over LoRaWAN and SCHC over Sigfox (Two-
   byte Option 2) uplink fragmentation profiles include:

   *  WINDOW_SIZE (tiles per window).

   *  M size (maximum number of windows).

   *  N size (tiles per window).

   *  Different RCS size and algoritm.

   SCHC over LoRaWAN ACK-on-Error includes a WINDOW_SIZE of 64 tiles.
   This allows feedback from receiver to sender with larger ACKs.
   Larger ACKs provide better performance in error-prone environments.

   On the other hand, SCHC over Sigfox leverages the Compound ACK with a
   WINDOW_SIZE of 32, allowing more downlink opportunities, and enabling
   larger ACKs, notifying more than one window, in error-prone
   environments and smaller ACKs, notifying one window.

   Therefore, the SCHC over All Profile uses smaller WINDOW_SIZE values
   than the ones proposed in SCHC over LoRaWAN [RFC9011], as it uses the
   Compound ACK to accomplish larger ACK size, while still having the
   option of smaller ACKs and more downlink opportunities.

   In error-prone environments, larger ACKs pool more fragment error in
   a single ACK, reducing the total number of ACKs, compared to the
   increase in ACK size.  Smaller ACKs performed better when error are
   scatter, as ACKs will be small and less frequent.

4.3.1.  Uplink ACK-on-Error Mode: Two-byte SCHC Header

   In order to take advance of the similarities of the different LPWAN
   profiles, the SCHC Uplink Fragmentation Header size is RECOMMENDED to
   have a size of 16 bits and be composed as follows:

   *  Rule ID size is: 8 bits

   *  DTag size (T) is: 0 bits

   *  Window index (W) size (M): 3 bits

   *  Fragment Compressed Number (FCN) size (N): 5 bits.

   *  MAX_ACK_REQUESTS: 5




Aguilar, et al.         Expires 12 November 2023                [Page 8]

Internet-Draft              SCHC Convergence                    May 2023


   *  WINDOW_SIZE: 31 (with a maximum value of FCN=0b1011)

   *  Regular tile size: 10 bytes

   *  All-1 tile size: 1 to 10 bytes

   *  Retransmission Timer: Application-dependent.  The RECOMMENDED
      value is 12 hours.

   *  Inactivity Timer: Application-dependent.  The RECOMMENDED value is
      12 hours.

   *  RCS size: 32 bits

4.3.2.  Downlink Consideration in Uplink Fragmentation

   When fragmentation is performed in the Uplink, the Compound ACK
   allows to optimally manage receiver acknowledgements, as the number
   of windows and the moment the Compound ACK is transferred can be
   freely selected, e.g., depending on network conditions or capacity.
   This advantage, compared with [RFC8724] and [RFC9011], benefits
   smaller windows sizes, as smaller windows sizes provide more downlink
   opportunities than a larger windows for the same number of tiles.

4.4.  Rule Management

   The RuleID MUST be 8 bits.  In LoRaWAN it MUST be encoded in the
   LoRaWAN FPort.

4.5.  SCHC over All F/R Message Formats

   This section depicts the different formats of SCHC Fragment, SCHC ACK
   (including the SCHC Compound ACK defined in
   [I-D.ietf-lpwan-schc-compound-ack]), SCHC Aborts and ACK Request used
   in SCHC over All Uplink ACK-on-Error mode.

4.5.1.  Regular SCHC Fragment

   Figure 4 shows an example of a regular SCHC fragment for all
   fragments except the last one.  The penultimate tile of a SCHC Packet
   is of the regular size.

      + ------ + -------------------------- +
      | RuleID |   W    |  FCN   |  Payload |
      + ------ + ------ + ------ + -------- +
      | 8 bits | 3 bits | 5 bits | Variable |

                      Figure 4: Regular SCHC Fragment



Aguilar, et al.         Expires 12 November 2023                [Page 9]

Internet-Draft              SCHC Convergence                    May 2023


4.5.2.  All-1 SCHC Fragment

      + ------ + ---------------------------- +
      | RuleID |   W    | FCN=All-1 |  RCS    |
      + ------ + ------ + --------- + ------- +
      | 8 bits | 3 bits | 5 bits    | 32 bits |

                  Figure 5: All-1 SCHC Fragment (no tile)

 + ------ + ---------------------------------------------------------- +
 | RuleID |   W    | FCN=All-1 |  RCS    |  Last tile   | Opt. padding |
 + ------ + ------ + --------- + ------- + ------------ + ------------ +
 | 8 bits | 3 bits |  5 bits   | 32 bits | 1 to X bits  | 0 to 7 bits

              Figure 6: All-1 SCHC Fragment (with tile)

4.5.3.  SCHC ACK Format

      + ------ + --------------------------+
      | RuleID |   W   | C = 1 |  padding  |
      + ------ + ----- + ----- + --------- +
      | 8 bits | 3 bit | 1 bit |  X bits   |

                       Figure 7: Successful SCHC ACK

     | FPort  | LoRaWAN payload                                      |
     + ------ + --------------------------------- + ---------------- +
     | RuleID |   W   | C = 0 | Compressed bitmap | Optional padding |
     |        |       |       |      (C = 0)      |    (b'0...0)     |
     + ------ + ----- + ----- + ----------------- + ---------------- +
     | 8 bits | 2 bit | 1 bit |    5 to 63 bits   |  0, 6 or 7 bits  |



     |-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
     +------+------+-------+--------+...+------+--------+------+-------+
     |RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000  |b'0-pad|
     +------+------+-------+--------+...+------+--------+------+-------+
     |8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|


        Losses are found in windows W = w1,...,wi; where w1<w2<...<wi

                        Figure 8: Failure SCHC ACK

4.5.4.  SCHC Receiver-Abort Message





Aguilar, et al.         Expires 12 November 2023               [Page 10]

Internet-Draft              SCHC Convergence                    May 2023


       |-- Receiver-Abort Header -|
       +-----------------------------------+-----------------+---------+
       | RuleID | W=b'111 | C=b'1 | b'1111 |  0xFF (all 1's) | b'0-pad |
       +--------+---------+-------+--------+-----------------+---------+
       | 8 bits |  3 bits | 1 bit | 4 bit  |  8 bit          |  X bits |
                   next L2 Word boundary ->| <-- L2 Word --> |

                      Figure 9: SCHC Receiver-Abort

4.5.5.  SCHC Sender-Abort Messages

         |---- Sender-Abort Header ----|
         +-----------------------------+
         | RuleID |   W    | FCN=ALL-1 |
         +--------+--------+-----------+
         | 8 bits | 3 bits |  5 bits   |

                        Figure 10: SCHC Sender-Abort

4.5.6.  SCHC ACK Request

      |------- ACK Request Header -------|
      +------- +------------------------ +
      | RuleID |    W   | FCN = b'00000  |
      + ------ + ------ + -------------- +
      | 8 bits | 3 bits | 5 bits         |

                        Figure 11: SCHC ACK Request

5.  Acknowledgements

   Carles Gomez has been funded in part by the Spanish Government
   through the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant
   (funded by MCIN / AEI / 10.13039/501100011033), and by Secretaria
   d'Universitats i Recerca del Departament d'Empresa i Coneixement de
   la Generalitat de Catalunya 2017 through grant SGR 376.

   Sergio Aguilar has been funded by the ERDF and the Spanish Government
   through project TEC2016-79988-P and project PID2019-106808RA-I00,
   AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).

6.  Normative References









Aguilar, et al.         Expires 12 November 2023               [Page 11]

Internet-Draft              SCHC Convergence                    May 2023


   [I-D.ietf-lpwan-schc-compound-ack]
              Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L.,
              Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in
              Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-
              ack-07, October 2022, <http://www.ietf.org/internet-
              drafts/draft-ietf-lpwan-schc-compound-ack-07.txt>.

   [I-D.lpwan-schc-over-nbiot]
              Ramos, E. and A. Minaburo, "SCHC over NBIoT", Work in
              Progress, Internet-Draft, draft-ietf-lpwan-schc-over-
              nbiot-12, October 2022, <http://www.ietf.org/internet-
              drafts/draft-ietf-lpwan-schc-over-nbiot-12.txt>.

   [I-D.lpwan-schc-over-sigfox]
              Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L.,
              Cespedes, S., Wistuba, D., and J. Boite, "SCHC over Sigfox
              LPWAN", Work in Progress, Internet-Draft, draft-ietf-
              lpwan-schc-over-sigfox-13, October 2022,
              <http://www.ietf.org/internet-drafts/draft-ietf-lpwan-
              schc-over-sigfox-13.txt>.

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

   [RFC9011]  Gimenez, O., Ed. and I. Petrov, Ed., "Static Context
              Header Compression and Fragmentation (SCHC) over LoRaWAN",
              RFC 9011, DOI 10.17487/RFC9011, April 2021,
              <https://www.rfc-editor.org/info/rfc9011>.

Authors' Addresses

   Sergio Aguilar
   Universitat Politecnica de Catalunya
   C/Esteve Terradas, 7
   08860 Castelldefels
   Spain
   Email: sergio.aguilar.romero@upc.edu







Aguilar, et al.         Expires 12 November 2023               [Page 12]

Internet-Draft              SCHC Convergence                    May 2023


   Carles Gomez
   Universitat Politecnica de Catalunya
   C/Esteve Terradas, 7
   08860 Castelldefels
   Spain
   Email: carles.gomez@upc.edu


   Rafael Vidal
   Universitat Politecnica de Catalunya
   C/Esteve Terradas, 7
   08860 Castelldefels
   Spain
   Email: rafael.vidal@upc.edu





































Aguilar, et al.         Expires 12 November 2023               [Page 13]