diff --git a/developer/workflows/onos-apps.md b/developer/workflows/onos-apps.md
index 105276a..352cbfa 100644
--- a/developer/workflows/onos-apps.md
+++ b/developer/workflows/onos-apps.md
@@ -115,7 +115,7 @@
 
 
 ```yaml
-aaaAppUrl: "myregistrydomain.com:30160/repository/aaa-app-1.10.0-SNAPSHOT.oar"
+aaaAppUrl: "http://myregistrydomain.com:30160/repository/aaa-app-1.10.0-SNAPSHOT.oar"
 aaaAppVersion: "1.10.0.SNAPSHOT"
 ```
 
@@ -128,5 +128,5 @@
 ```
 
 > You can find a full list of the application names and URLs here:
-> - https://github.com/opencord/helm-charts/blob/master/xos-profiles/seba-services/values.yaml#L43-L53 
-> - https://github.com/opencord/helm-charts/blob/master/workflows/att-workflow/values.yaml#L40-L41
\ No newline at end of file
+> - https://github.com/opencord/helm-charts/blob/master/xos-profiles/seba-services/values.yaml#L43-L53
+> - https://github.com/opencord/helm-charts/blob/master/workflows/att-workflow/values.yaml#L40-L41
diff --git a/installation/platform.md b/installation/platform.md
index d8666fc..67deb21 100644
--- a/installation/platform.md
+++ b/installation/platform.md
@@ -10,7 +10,7 @@
 Then, to install the CORD Platform you can use the corresponding chart:
 
 ```shell
-helm install -n cord-platform cord/cord-platform --version=6.1.0
+helm install -n cord-platform cord/cord-platform --version=7.0.0
 ```
 
 ### Disabling monitoring and logging
@@ -28,7 +28,7 @@
 To disable both of them you can use:
 
 ```shell
-helm install -n cord-platform cord/cord-platform --version=6.1.0 --set logging.enabled=false --set nem-monitoring.enabled=false
+helm install -n cord-platform cord/cord-platform --version=7.0.0 --set logging.enabled=false --set nem-monitoring.enabled=false
 ```
 
 ## Alternatively, install the CORD Platform as set of Separate Components
diff --git a/operating_cord/elk_stack.md b/operating_cord/elk_stack.md
index 6546452..80c2326 100644
--- a/operating_cord/elk_stack.md
+++ b/operating_cord/elk_stack.md
@@ -196,4 +196,33 @@
   }
 }
 ' | jq .hits.hits
-```
\ No newline at end of file
+```
+
+### Get Operational status of the RADIUS server
+
+Operational status can be queried from Elastic search using Rest API calls.
+Three possible values for operational status are: 
+1) In Use
+2) Unknown
+3) Unavailable 
+
+```bash
+curl -XGET "http://localhost:$ELK_PORT/_search" -H 'Content-Type: application/json' -d'
+{
+  "query": {
+    "bool": {
+      "filter": {
+        "term": {
+          "kafka_topic": "radiusoperationalstatus.events"
+        }
+      }
+    }
+  }
+}' | jq .hits.hits[0]._source.radiusoperationalstatus
+```
+
+Example Response:
+
+```bash
+"In Use"
+```
diff --git a/prereqs/hardware.md b/prereqs/hardware.md
index dabfe11..6f1173e 100644
--- a/prereqs/hardware.md
+++ b/prereqs/hardware.md
@@ -84,7 +84,7 @@
             * Celestica Tellion GP-1204
             * Movistar ONU (with CPE included) (manifactured by Telefonica: <http://www.movistar.es/particulares/movil/moviles/hgu>)
     * **XGS-PON**
-        * **OLT**: EdgeCore ASFVOLT16 (for more info <bartek_raszczyk@edge-core.com>)
+        * **OLT**: Edgecore ASXvOLT16 (for more info <bartek_raszczyk@edge-core.com>)
             * Compatible **OLT optics**
                 * Hisense/Ligent: LTH7226-PC, LTH7226-PC+
                 * Source Photonics: XPP-XG2-N1-CDFA
diff --git a/profiles/seba/configuration.md b/profiles/seba/configuration.md
index 780ea1a..0df79b0 100644
--- a/profiles/seba/configuration.md
+++ b/profiles/seba/configuration.md
@@ -6,8 +6,8 @@
 
 In this page we are describing the process as a three steps process:
 
-- [Fabric Setup](./configuration.md#fabric-setup)
-- [OLT Provisioning](./configuration.md#olt-provisioning)
+- [POD Setup](./configuration.md#pod-setup)
+- [PON Provisioning](./configuration.md#pon-provisioning)
 - [Subscriber Provisioning](./configuration.md#subscriber-provisioning)
 
 as that is what logically makes sense, but be aware that all the configurations
@@ -17,7 +17,15 @@
 you will need to create your own, but the following can serve as a
 reference:
 
-## Fabric Setup
+## POD Setup
+
+The POD Setup consists of
+
+- Fabric configuration (In this case a single aggregation switch, see [Fabric](../../fabric/README.md) for more information)
+- `BNGPortMapping` configuration (see [Fabric-crossconnet](../../fabric-crossconnect/README.md) for more information)
+- DHCP L2 Relay configuration (see [ONOS DHCP L2 RELAY Application](https://github.com/opencord/dhcpl2relay/#configuration) for more information)
+
+For simplicity this is encapsulated in a single TOSCA recipe:
 
 ```yaml
 tosca_definitions_version: tosca_simple_yaml_1_0
@@ -103,7 +111,13 @@
 For instructions on how to push TOSCA into a CORD POD, please
 refer to this [guide](../../xos-tosca/README.md).
 
-## OLT Provisioning
+## PON Provisioning
+
+The PON Provisioning consists of preparing all the configurations needed by ONOS and VOLTHA to manage the PON network,
+su as:
+
+- [OLT](../../olt-service/README.md#create-an-OLT)
+- [Technology Profile](https://github.com/opencord/voltha/tree/master/common/tech_profile)
 
 ```yaml
 tosca_definitions_version: tosca_simple_yaml_1_0
@@ -111,6 +125,7 @@
   - custom_types/oltdevice.yaml
   - custom_types/onudevice.yaml
   - custom_types/voltservice.yaml
+  - custom_types/technologyprofile.yaml
 description: Create an OLT Device in VOLTHA
 topology_template:
   node_templates:
@@ -128,16 +143,78 @@
         device_type: openolt
         host: 10.90.0.122
         port: 9191
-        switch_datapath_id: of:0000000000000002 # the openflow switch to which the OLT is connected
+        switch_datapath_id: of:0000000000000002 # the openflow id of the switch to which the OLT is connected
         switch_port: "1" # the port on the switch on which the OLT is connected
         outer_tpid: "0x8100"
         uplink: "65536"
         nas_id: "NAS_ID"
-        serial_number: "10.90.0.122:9191"
+        serial_number: EC1721000208 # the serial number of the OLT device
       requirements:
         - volt_service:
             node: service#volt
             relationship: tosca.relationships.BelongsToOne
+            
+    technologyProfile:
+      type: tosca.nodes.TechnologyProfile
+      properties:
+        profile_id: 64
+        technology: xgspon
+        profile_value: >
+          {
+            "name": "4QueueHybridProfileMap1",
+            "profile_type": "XPON",
+            "version": 1.0,
+            "num_gem_ports": 1,
+            "instance_control": {
+              "onu": "multi-instance",
+              "uni": "single-instance",
+              "max_gem_payload_size": "auto"
+            },
+            "us_scheduler": {
+              "additional_bw": "auto",
+              "direction": "UPSTREAM",
+              "priority": 0,
+              "weight": 0,
+              "q_sched_policy": "hybrid"
+            },
+            "ds_scheduler": {
+              "additional_bw": "auto",
+              "direction": "DOWNSTREAM",
+              "priority": 0,
+              "weight": 0,
+              "q_sched_policy": "hybrid"
+            },
+            "upstream_gem_port_attribute_list": [{
+                "pbit_map": "0b11000000",
+                "aes_encryption": "True",
+                "scheduling_policy": "StrictPriority",
+                "priority_q": 1,
+                "weight": 0,
+                "discard_policy": "TailDrop",
+                "max_q_size": "auto",
+                "discard_config": {
+                  "min_threshold": 0,
+                  "max_threshold": 0,
+                  "max_probability": 0
+                }
+              }
+            ],
+            "downstream_gem_port_attribute_list": [{
+                "pbit_map": "0b11000000",
+                "aes_encryption": "True",
+                "scheduling_policy": "StrictPriority",
+                "priority_q": 1,
+                "weight": 0,
+                "discard_policy": "TailDrop",
+                "max_q_size": "auto",
+                "discard_config": {
+                  "min_threshold": 0,
+                  "max_threshold": 0,
+                  "max_probability": 0
+                }
+              }
+            ]
+          }
 ```
 
 For instructions on how to push TOSCA into a CORD POD, please
@@ -147,6 +224,8 @@
 
 Once the POD has been configured, you can create a subscriber.
 
+This section will guide you through the configuration of `Subscriber` and associated `BandwidthProfile`s.
+
 To create a subscriber, you'll need to know the serial number of the ONU it is
 attached to.
 
@@ -221,17 +300,41 @@
 tosca_definitions_version: tosca_simple_yaml_1_0
 imports:
   - custom_types/rcordsubscriber.yaml
+  - custom_types/bandwidthprofile.yaml
 description: Create a test subscriber
 topology_template:
   node_templates:
+  
+    high_speed_bp:
+      type: tosca.nodes.BandwidthProfile
+      properties:
+         air: 2000
+         cbs: 2000
+         cir: 2000
+         ebs: 2000
+         eir: 2000
+         name: High Speed Internet
+
     # A subscriber
     my_house:
       type: tosca.nodes.RCORDSubscriber
       properties:
         name: My House
+        status: pre-provisioned # the status we want to create the subscriber in
         c_tag: 111
         s_tag: 222
-        onu_device: BRCM1234 # Serial Number of the ONU Device to which this subscriber is connected
+        onu_device: BRCM22222222 # Serial Number of the ONU Device to which this subscriber is connected
+        tech_profile_id: 64 # The ID of the technology profile that needs to be applied to this subscriber
+        nas_port_id : some-value # radius specific attributes
+        circuit_id: some-value # radius specific attributes
+        remote_id: some-value # radius specific attributes
+      requirements:
+        - upstream_bps:
+            node: high_speed_bp
+            relationship: tosca.relationships.BelongsToOne
+        - downstream_bps:
+            node: high_speed_bp
+            relationship: tosca.relationships.BelongsToOne
 ```
 
 For instructions on how to push TOSCA into a CORD POD, please
diff --git a/profiles/seba/install.md b/profiles/seba/install.md
index 8b18206..c9761dc 100644
--- a/profiles/seba/install.md
+++ b/profiles/seba/install.md
@@ -24,7 +24,7 @@
 Then, proceed with the SEBA chart installation:
 
 ```shell
-helm install -n seba cord/seba --version=1.0.0
+helm install -n seba cord/seba --version=2.0.0-alpha1
 ```
 
 ### Alternatively, install SEBA as separate components
diff --git a/profiles/seba/known-issues.md b/profiles/seba/known-issues.md
index f9fb8f8..78fbfad 100644
--- a/profiles/seba/known-issues.md
+++ b/profiles/seba/known-issues.md
@@ -1,35 +1,20 @@
 # Known Issues
 
-## SEBA 1.0 Release
+## SEBA 2.0-alpha Release
 
-There are known major issues having to do with rebooting of the physical hardware, both
-the OLT and the AGG switch, as well as continuously deleting/re-creating of an OLT Device via NEM. These issues are described in more detail in below:
+This release of SEBA is qualified as 'alpha' due to known major issues related to the use of OLT software from Broadcom referred to as BAL - Broadband Adaptation Layer. The SEBA 2.0-alpha release uses [BAL 2.6](https://github.com/balapi/bal-api-2.6), which is no longer supported by Broadcom.
 
-* [SEBA-388](https://jira.opencord.org/browse/SEBA-388)
-   With this issue, DHCP may not work after AGG switch reboot. A possible workaround is to use a different config for the DHCPl2Relay app that uses the OLT's uplink to reach the DHCP Server, instead of the Switch's uplink. More details are described [here](troubleshoot/no-dhcp.md)
-* [SEBA-385](https://jira.opencord.org/browse/SEBA-385)
-   With this issue, the OLT may not pass traffic anymore after reboot. Currently, the only workaround is to, enter the ONOS CLI and force a 'device-remove <&lt;device-id>' for the device from VOLTHA (in other words, force VOLTHA to reconnect to ONOS), and then perform the authentication/dhcp steps again for the subscribers
-* [SEBA-393](https://jira.opencord.org/browse/SEBA-393)
-   With this issue, if an OLT device gets deleted and re-created many times within a short period of time (10+ times within an hour or so), VOLTHA may run into an issue where it's unable to save any information pertaining the OLT device such as its ports or any ONU devices connected to those ports. The workaround for this issue is to re-install VOLTHA and re-create the OLT device through NEM.
+These issues are described in more detail in below:
 
-Fixes to these issues will be addressed soon after the release.
+* [SEBA-670](https://jira.opencord.org/browse/SEBA-670)
+   This issue can be triggered by disable and subsequent re-enable of the ONU via NEM (or VOLTHA). In the SEBA pod, using the AT&T workflow, these actions are accompanied by the removal of subscriber flows upon disable of the ONU, and the reprogramming of eapol flows upon re-enable of the ONU. An irrecoverable error is seen in BAL (specifically bal_core_dist) which does not allow flows to be added to the OLT. As a result authentication of RG's fail.
+* [SEBA-775](https://jira.opencord.org/browse/SEBA-775)
+   This issue is closely related to SEBA-670. The fundamental issue is the removal of flows in the OLT which possibly leaves behind state in BAL 2.6 that does not allow the subsequent reprogramming of flows. It can be triggered by the disable/re-enable of ONUs (as in SEBA-670) or by the remove-subscriber followed by the add-subscriber calls (without change of ONU state). It can be triggered in systems with a single-ONU, as well as in multi-ONU cases. Empirically the issue is more easily reproduced in multi-ONU scenarios. It is observed with single gem ports as well as when multiple gem ports are used for a subscriber in the technology profile.
+* [SEBA-777](https://jira.opencord.org/browse/SEBA-777)
+   Due to the issues mentioned above, subscriber speed profiles cannot be updated reliably, as the update requires the removal of subscriber flows that point to a bandwidth meter, and the reprogramming of flows that point to a new meter.
+* [SEBA-776](https://jira.opencord.org/browse/SEBA-776)
+   This issue is seen sometimes with the use of multiple gem ports in a technology profile. Packet duplication appears to mirror the number of gem ports - using 4 gem ports results in 4 packets for every packet transmitted.
 
-Another minor issue that does not affect functionality is related to the state of an ONU on the VOLTHA CLI, after disable/re-enable of the ONU.
+Fixes to these issues will be addressed in a future release  as we upgrade the OLT software to BAL 3.0.
 
-```shell
-(voltha) devices
-Devices:
-+------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
-|               id |              type | root |        parent_id |    serial_number | admin_state | oper_status | connect_status | parent_port_no |    host_and_port |                 reason | proxy_address.device_id | proxy_address.channel_id | proxy_address.onu_id | proxy_address.onu_session_id |
-+------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
-| 0001a82d21249c28 |           openolt | True | 000100000a5a007a | 10.90.0.122:9191 |     ENABLED |      ACTIVE |      REACHABLE |                | 10.90.0.122:9191 |                        |                         |                          |                      |                              |
-| 00014f81e9f21dbb | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cf9d |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    1 |                            1 |
-| 0001666321e17127 | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1ced5 |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    2 |                            2 |
-| 000175a511654437 | brcm_openomci_onu | True | 0001a82d21249c28 |     ISKT71e80080 |     ENABLED |      ACTIVE |      REACHABLE |      536870927 |                  |      omci-flows-pushed |        0001a82d21249c28 |                       15 |                    1 |                            1 |
-| 0001cb66a703449d | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cfe3 |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    3 |                            3 |
-| 0001246c72a99ddd | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cf8e |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    4 |                            4 |
-| 000192f54601ecb4 | brcm_openomci_onu | True | 0001a82d21249c28 |     ALPHe3d1cf70 |     ENABLED |      ACTIVE |      REACHABLE |      536870912 |                  | initial-mib-downloaded |        0001a82d21249c28 |                          |                    5 |                            5 |
-+------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
-```
-
-In the `reason` column of the devices table, the state of the ONU devices are displayed. Normally after an ONU is disabled, and then re-enabled, it should display the `initial-mib-downloaded` state, indicating that the RG behind the ONU should be ready to re-authenticate (as per the AT&T workflow). However, in this release, the state is incorrectly displayed as `omci-flows-pushed`. This does not affect authentication, dhcp or the subscribers.
+In addition, OLT-reboot [SEBA-385](https://jira.opencord.org/browse/SEBA-385) can result in some ONUs not returning to ACTIVE state in VOLTHA.
diff --git a/profiles/seba/siab.md b/profiles/seba/siab.md
index 84f6eb3..d81a26c 100644
--- a/profiles/seba/siab.md
+++ b/profiles/seba/siab.md
@@ -31,11 +31,14 @@
 To build a SiaB that uses the released service versions specified in the Helm charts:
 
 ```bash
-make    # or 'make stable'
+make [stable] [NUM_OLTS=n] [NUM_ONUS_PER_OLT=m]    # `make` and `make stable` are the same
 ```
 
 > NOTE that `make` or `make stable` will install SEBA with the container versions that are
-> defined in the helm charts. If you want to install SEBA 1.0 please use: `make siab-1.0`
+> defined in the helm charts. If you want to install SEBA 2.0 please use: `make siab-2.0-alpha1`
+
+You can specify the number of OLTs (up to 4) and number of ONUs per OLT (up to 4) that you want to
+create.
 
 After a successful install, you will see the message:
 
@@ -57,60 +60,18 @@
 make run-tests
 ```
 
+Note that the tests currently assume a single OLT/ONU, so some tests will
+likely fail if you have configured multiple OLTs and ONUs.
+
 ### Quick start: Build SiaB using latest development code
 
 To build a SiaB that uses the latest development code:
 
 ```bash
-make latest [NUM_OLTS=n]
+make latest [NUM_OLTS=n] [NUM_ONUS_PER_OLT=m]
 ```
-
-With the `latest` target, you can specify the number of OLT/ONU/RG chains (up to 4) that you want to
-create.  Each OLT associates with a single ONU; adding multiple ONUs per OLT is future work.  If you
-specify more than one OLT you will see several OLT/ONU/RG containers when you run `kubectl -n voltha
-get pod`:
-
-```bash
-$ kubectl -n voltha get pod
-NAME                                        READY   STATUS    RESTARTS   AGE
-...
-olt0-774f9cb5f7-2z256                       1/1     Running   0          6m31s
-olt1-5f7c44f554-rkdbq                       1/1     Running   0          6m31s
-olt2-d949c6c9f-jcmgz                        1/1     Running   0          6m31s
-onu0-7db8455577-8n8ks                       1/1     Running   0          6m30s
-onu1-d64b87d79-kqmd5                        1/1     Running   0          6m31s
-onu2-5bb54b889-8g6w8                        1/1     Running   0          6m31s
-rg0-84b6654764-ztb4r                        1/1     Running   0          6m30s
-rg1-b8ccb5cfd-r2586                         1/1     Running   0          6m30s
-rg2-574c7d9f6-f5knh                         1/1     Running   0          6m30s
-...
-```
-
-Likewise `brctl show` will output:
-
-```bash
-$ brctl show
-bridge name bridge id           STP enabled   interfaces
-docker0     8000.02429b163213   no
-nni0        8000.e62fcf80f1ed   no            vethac65f4a9
-                                              vethcdad8664
-nni1        8000.06298b5e03f5   no            veth4c8048bf
-                                              vethdd2f29d1
-nni2        8000.aef29aa3595a   no            vetha7186d8a
-                                              vethd9610930
-pon0        8000.a24b3df352ac   no            veth1b61ec08
-                                              veth3f1056c1
-pon1        8000.824c4346fb80   no            veth631eb0a8
-                                              vethdae92661
-pon2        8000.6e30a2216b3c   no            veth66b840fa
-                                              veth72f061ad
-```
-
-Above there are three separate datapath chains: `rg0 -> pon0 -> onu0 -> olt0 -> nni0`, `rg1 -> pon1
--> onu1 -> olt1 -> nni1`, etc.  All of the `nniX` bridges connect to the agg switch in Mininet on
-different ports.   A subscriber is created for each RG `rgX` with S-tag of `222+X` and C-tag of
-`111`.  After `rgX` is authenticated, it will get an IP address on subnet `172.18.X.0/24` and ping
-`172.18.X.10` as its BNG.
+You can specify the number of OLTs (up to 4) and number of ONUs per OLT (up to 4) that you want to
+create.
 
 After a successful install, you will see the message:
 
@@ -126,11 +87,12 @@
 make run-tests-latest
 ```
 
-Note that the tests currently assume a single OLT, so some tests will likely fail if you have configured multiple OLTs.
+Note that the tests currently assume a single OLT/ONU, so some tests will
+likely fail if you have configured multiple OLTs and ONUs.
 
 ## Installation procedure
 
-The rest of this page describes a manual method for installing SEBA-in-a-Box.
+The rest of this page describes a manual method for installing SEBA-in-a-Box.  It also provides an overview of what is installed by each chart.
 
 ### Prerequisites
 
@@ -219,7 +181,7 @@
 Install the `cordctl` command line tool:
 
 ```bash
-export CORDCTL_VERSION=1.0.0
+export CORDCTL_VERSION=1.1.1
 export CORDCTL_PLATFORM=linux-amd64
 curl -L -o /tmp/cordctl "https://github.com/opencord/cordctl/releases/download/$CORDCTL_VERSION/cordctl-$CORDCTL_PLATFORM"
 sudo mv /tmp/cordctl /usr/local/bin/cordctl
@@ -255,6 +217,16 @@
 helm install -n onos onos
 ```
 
+You should see the following pods running:
+
+```bash
+$ kubectl get pod
+NAME                     READY   STATUS    RESTARTS   AGE
+cord-kafka-0             1/1     Running   1          14h
+cord-kafka-zookeeper-0   1/1     Running   0          14h
+onos-558445d9bc-c2cd5    2/2     Running   0          14h
+```
+
 ## Install VOLTHA charts
 
 Run these commands to install VOLTHA:
@@ -269,57 +241,83 @@
 kubectl get crd | grep etcd
 # After EtcdCluster CRD is in place
 helm dep up voltha
-helm install -n voltha -f configs/seba-ponsim.yaml voltha
+helm install -n voltha voltha  --set etcd-cluster.clusterSize=1
 ```
 
 **Before proceeding**
 
-Run: `kubectl get pod|grep etcd-cluster`
+Run: `kubectl get pod -l app=etcd`
 
 You should see the etcd-cluster pod up and running.
 
 ```bash
-$ kubectl get pod|grep etcd-cluster
-etcd-cluster-q9zhrwvllh                                       1/1       Running     0          20m
+$ kubectl get pod -l app=etcd
+NAME                      READY   STATUS    RESTARTS   AGE
+etcd-cluster-jcjk2x97w6   1/1     Running   0          14h
 ```
 
+You should see the VOLTHA pods created:
+
+```bash
+$ kubectl get pod -n voltha
+NAME                                        READY   STATUS    RESTARTS   AGE
+default-http-backend-798fb4f44c-fb696       1/1     Running   0          14h
+freeradius-754bc76b5-22lcm                  1/1     Running   0          14h
+netconf-66b767bddc-hbsgr                    1/1     Running   0          14h
+nginx-ingress-controller-5fc7b87c86-bd55x   1/1     Running   0          14h
+ofagent-556cd6c978-lknd4                    1/1     Running   0          14h
+vcli-67c996f87d-vw4pk                       1/1     Running   0          14h
+vcore-0                                     1/1     Running   0          14h
+voltha-6f8d7bf7b-4gkkj                      1/1     Running   1          14h
+```
+
+
 ## Install Ponsim charts
 
 Run these commands to install Ponsim (after installing VOLTHA):
 
 ```bash
 cd ~/cord/helm-charts
-helm install -n ponnet ponnet
+NUM_OLTS=1          # can be between 1 and 4
+NUM_ONUS_PER_OLT=1  # can be between 1 and 4
+helm install -n ponnet ponnet --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
 # Wait for CNI changes
 ~/cord/helm-charts/scripts/wait_for_pods.sh kube-system
-helm install -n ponsimv2 ponsimv2
+helm install -n ponsimv2 ponsimv2 --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
 # Iptables setup
 sudo iptables -P FORWARD ACCEPT
 ```
 
+Setting `numOlts` and `numOnus` is optional; the default is 1.
+
 **Before proceeding**
 
-Run: `kubectl -n voltha get pod`
+Run: `kubectl -n voltha get pod -l app=ponsim`
 
-Make sure that all of the pods in the voltha namespace are in Running state.
 
 ```bash
-$ kubectl -n voltha get pod
-NAME                                        READY     STATUS    RESTARTS   AGE
-default-http-backend-846b65fb5f-rklfb       1/1       Running   0          6h
-freeradius-765c9b486c-6qs7t                 1/1       Running   0          6h
-netconf-7d7c96c88b-29cv2                    1/1       Running   0          6h
-nginx-ingress-controller-6db99757f7-d9cpk   1/1       Running   0          6h
-ofagent-7d7b854cd4-fx6gq                    1/1       Running   0          6h
-olt0-5455744678-hqbwh                       1/1       Running   0          6h
-onu0-5df655b9c9-prfjz                       1/1       Running   0          6h
-rg0-75845c54bc-fjgrf                        1/1       Running   0          6h
-vcli-6875544cf-rfdrh                        1/1       Running   0          6h
-vcore-0                                     1/1       Running   0          6h
-voltha-546cb8fd7f-5n9x4                     1/1       Running   3          6h
+$ kubectl -n voltha get pod -l app=ponsim
+NAME                      READY   STATUS    RESTARTS   AGE
+olt0-f4744dc5-xdrjb       1/1     Running   0          15h
+onu0-0-6bf67bf6c6-76gn7   1/1     Running   0          15h
+rg0-0-7b9d5cdb5c-jc8p5    1/1     Running   0          14h
 ```
 
-If you see the olt pod in CrashLoopBackOff state, try deleting (`helm delete --purge`) and reinstalling the ponsimv2 chart.
+Make sure that all of the pods in the voltha namespace are in Running state.
+If you see the `olt0` pod in CrashLoopBackOff state, try deleting (`helm delete --purge`) and reinstalling the ponsimv2 chart.
+
+If you install more than one OLT/ONU then you will see more containers above.  The naming convention:
+```
+1st OLT - olt0-xxx
+2nd OLT - olt1-xxx
+1st ONU attached to 1st OLT - onu0-0-xx (onu<olt>-<onu>)
+2nd ONU attached to 1st OLT - onu0-1-xx
+1st ONU attached to 2nd OLT - onu1-0-xx
+2nd ONU attached to 2nd OLT - onu1-1-xx
+RG follows the same naming logic as ONU (rg0-0-xx, rg0-1-xx, rg1-0-xx, rg1-1-xx)
+Linux bridges interconnecting ONU and RG follow the same naming logic as ONU (pon0.0, pon0.1 ...)
+Linux bridges interconnecting OLT and Mininet follow same naming logic as OLT (nni0, nni1, ...)
+```
 
 Run `http GET http://127.0.0.1:30125/health|jq '.state'`.  It should return `"HEALTHY"`:
 
@@ -328,6 +326,7 @@
 "HEALTHY"
 ```
 
+
 ## Install NEM charts
 
 Run these commands:
@@ -360,26 +359,26 @@
 Run these commands:
 
 ```bash
-helm install -n ponsim-pod xos-profiles/ponsim-pod
+helm install -n ponsim-pod xos-profiles/ponsim-pod --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
 ~/cord/helm-charts/scripts/wait_for_pods.sh
 ```
 
+The TOSCA creates a subscriber for each RG `rg<olt>-<onu>` with S-tag of `222+<olt>` and C-tag of `111+<onu>`.
+
 **Before proceeding**
 
-Log into the XOS GUI at `http://<hostname>:30001` (credentials: admin@opencord.org / letmein).  You should see an AttWorkflowDriver Service Instance with authentication state AWAITING.
-
-To run the check from the command line:
+Log into the XOS GUI at `http://<hostname>:30001` (credentials: admin@opencord.org / letmein).  You should see an AttWorkflowDriver Service Instance with authentication state AWAITING.  To check this from the command line:
 
 ```bash
 cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=AWAITING"
 ```
 
-This will show only the AttWorkflowDriver Service Instances in AWAITING state.  Wait until you see something like:
+This will show only the AttWorkflowDriver Service Instances in AWAITING state.  Wait until you see a line for each ONU:
 
 ```bash
 $ cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=AWAITING"
-OWNER_ID    SERIAL_NUMBER    OF_DPID                UNI_PORT_ID    STATUS_MESSAGE                                      ID    NAME
-2           PSMO12345678     of:0000aabbccddeeff    128            ONU has been validated - Awaiting Authentication    56
+ID    NAME    OF_DPID                OWNER_ID    SERIAL_NUMBER    STATUS_MESSAGE                                      UNI_PORT_ID
+56            of:0000d0d3e158fede    2           PSMO00000000     ONU has been validated - Awaiting Authentication    128
 ```
 
 ## Install Mininet
@@ -400,7 +399,7 @@
 
 ```bash
 cd ~/cord/helm-charts
-helm install -n mininet mininet
+helm install -n mininet mininet --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
 ~/cord/helm-charts/scripts/wait_for_pods.sh
 ```
 
@@ -416,30 +415,32 @@
 
 Run: `brctl show`
 
-You should see two interfaces on each of the pon0 and nni0 Linux bridges.
+You should see two interfaces on the `ponX.Y` and `nniX` Linux bridges.
 
 ```bash
 $ brctl show
 bridge name     bridge id               STP enabled     interfaces
 docker0         8000.02429d07b4e2       no
-pon0            8000.bec4912b1f6a       no              veth25c1f40b
+pon0.0          8000.bec4912b1f6a       no              veth25c1f40b
                                                         veth2a4c914f
 nni0            8000.0a580a170001       no              veth3cc603fe
                                                         vethb6820963
 ```
 
-## Enable pon0 to forward EAPOL packets
+You will see more bridges if you've configured multiple OLTs and ONUs.  All of the `nniX` Linux bridges connect to the agg switch in Mininet on different ports.
 
-This is necessary to enable the RG to authenticate.  Run these commands:
+## Enable pon bridges to forward EAPOL packets
+
+This is necessary to enable the RG to authenticate:
 
 ```bash
-echo 8 > /tmp/pon0_group_fwd_mask
-sudo cp /tmp/pon0_group_fwd_mask /sys/class/net/pon0/bridge/group_fwd_mask
+echo 8 > /tmp/group_fwd_mask
+for BRIDGE in /sys/class/net/pon*; do sudo cp /tmp/group_fwd_mask $BRIDGE/bridge/group_fwd_mask; done
 ```
 
 ## ONOS customizations
 
-Right now it’s necessary to install some custom configuration to ONOS directly.  Run this command:
+It’s necessary to install some custom configuration to ONOS directly.  Run this command:
 
 ```bash
 http -a karaf:karaf POST \
@@ -448,7 +449,7 @@
 
 The above command instructs the ONU to exchange untagged packets with the RG, rather than packets tagged with VLAN 0.
 
-At this point the system should be fully installed and functional.  
+At this point the system should be fully installed and functional.
 
 ## Validating the install
 
@@ -457,10 +458,11 @@
 Enter the RG pod in the voltha namespace:
 
 ```bash
-RG_POD=$( kubectl -n voltha get pod -l "app=rg0" -o jsonpath='{.items[0].metadata.name}' )
+RG_POD=$( kubectl -n voltha get pod | grep rg0-0 | awk '{print $1}' )
 kubectl -n voltha exec -ti $RG_POD bash
 ```
 
+If you built SiaB with multiple OLTs and ONUs, you can choose any RG to authenticate.
 Inside the pod, run this command:
 
 ```bash
@@ -484,8 +486,7 @@
 
 **Before proceeding**
 
-In the XOS GUI, the AttDriverWorkflow Service Instance should now be in APPROVED state.  
-You can check for this on the command line by running:
+In the XOS GUI, the AttDriverWorkflow Service Instance should now be in APPROVED state.  You can check for this on the command line by running:
 
 ```bash
 cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=APPROVED"
@@ -495,12 +496,11 @@
 
 ```bash
 $ cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=APPROVED"
-OF_DPID                UNI_PORT_ID    STATUS_MESSAGE                                       ID    NAME    OWNER_ID    SERIAL_NUMBER
-of:0000aabbccddeeff    128            ONU has been validated - Authentication succeeded    56            2           PSMO12345678
+ID    NAME    OF_DPID                OWNER_ID    SERIAL_NUMBER    STATUS_MESSAGE                                       UNI_PORT_ID
+56            of:0000d0d3e158fede    2           PSMO00000000     ONU has been validated - Authentication succeeded    128
 ```
 
-The FabricCrossconnect Service Instance should have a check in the Backend status column in the GUI.
-You can check for this on the command line by running:
+The FabricCrossconnect Service Instance should have a check in the Backend status column in the GUI.  You can check for this on the command line by running:
 
 ```bash
 cordctl model list FabricCrossconnectServiceInstance -f 'backend_status=OK'
@@ -510,8 +510,8 @@
 
 ```bash
 $ cordctl model list FabricCrossconnectServiceInstance -f 'backend_status=OK'
-SWITCH_DATAPATH_ID     SOURCE_PORT    ID    NAME    OWNER_ID    S_TAG
-of:0000000000000001    2              59            5           222
+ID    NAME    OWNER_ID    S_TAG    SOURCE_PORT    SWITCH_DATAPATH_ID
+59            4           222      2              of:0000000000000001
 ```
 
 ### Obtain an IP address for the RG
@@ -540,7 +540,7 @@
 
 **Before proceeding**
 
-Make sure that eth0 inside the RG container has an IP address on the 172.18.0.0/24 subnet:
+`rg<olt>-<onu>` will get an IP address on subnet `172.18+<olt>.<onu>.0/24`.  Make sure that eth0 inside the RG container has an IP address on the proper subnet:
 
 ```bash
 $ ifconfig eth0
@@ -555,7 +555,7 @@
 
 ### Ping the emulated BNG
 
-The emulated BNG has an IP address of 172.18.0.10.  After successfully running dhclient you should be able to ping it from the RG.
+`rg<olt>-<onu>` pings `172.18+<olt>.<onu>.10` as its BNG.
 
 ```bash
 $ ping -c 3 172.18.0.10
diff --git a/profiles/seba/workflows/att-install.md b/profiles/seba/workflows/att-install.md
index e1182de..3a80da0 100644
--- a/profiles/seba/workflows/att-install.md
+++ b/profiles/seba/workflows/att-install.md
@@ -5,7 +5,7 @@
 ## Install the `att-workflow` chart
 
 ```shell
-helm install -n att-workflow cord/att-workflow --version=1.0.2
+helm install -n att-workflow cord/att-workflow --version=1.2.4
 ```
 
 > NOTE: if you have installed the `cord-platform` chart as a sum of its components,
diff --git a/quickstart/seba_quickstart.md b/quickstart/seba_quickstart.md
index 10a9cc7..1aa43c0 100644
--- a/quickstart/seba_quickstart.md
+++ b/quickstart/seba_quickstart.md
@@ -6,26 +6,30 @@
 
 ## Install components as a whole
 
+The commands below will bring up the SEBA 2.0-alpha release
+
 ```shell
 # Add the CORD repository and update indexes
 helm repo add cord https://charts.opencord.org
 helm repo update
 
 # Install the CORD platform
-helm install -n cord-platform --version 6.1.0 cord/cord-platform
+helm install -n cord-platform --version 7.0.0 cord/cord-platform
 
 # Wait until 3 etcd CRDs are present in Kubernetes
 kubectl get crd | grep -i etcd | wc -l
 
 # Install the SEBA profile
-helm install -n seba --version 1.0.0 cord/seba
+helm install -n seba --version 2.0.0-alpha1 cord/seba
 
 # Install the AT&T workflow
-helm install -n att-workflow --version 1.0.2 cord/att-workflow
+helm install -n att-workflow --version 1.2.4 cord/att-workflow
 ```
 
 ## Alternatively, install as separate components
 
+The commands below will bring up SEBA using the latest released versions of the Helm charts.  The resulting system should work but it may not correspond to an official SEBA release.
+
 ```shell
 # Add the official Kubernetes incubator repostiory (for Kafka) and update the indexes
 helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator
@@ -63,12 +67,12 @@
 kubectl get crd | grep -i etcd | wc -l
 
 # Install the rest of the SEBA profile components
-helm install -n voltha cord/voltha
+helm install -n voltha --version 1.0.6 cord/voltha     # Install VOLTHA 1.7.0
 helm install -n seba-service cord/seba-services
 helm install -n base-kubernetes cord/base-kubernetes
 
 # Install the AT&T workflow
-helm install -n att-workflow --version 1.0.2 cord/att-workflow
+helm install -n att-workflow cord/att-workflow
 ```
 
 ## Verify your installation and next steps