Our video tutorials are only available for viewing at our website with an internet connection (no offline option).
Public Course Schedule
August 20*EMEA Time Zone* Technology Primer: Containers and Microservices in Telecom
August 24Technology Primer: Voice over Wi-Fi (VoWiFi)
August 27Technology Primer: Network Slicing in 5G
September 6*EMEA Time Zone* Technology Primer: LTE-M and NB-IoT
September 6Advanced LPWA for IoT
September 10*EMEA Time Zone* Technology Primer: Orchestration
September 10SDN and NFV Architecture and Operations
September 10Technology Primer: Cloud and Virtualization
September 10Technology Primer: Containers and Microservices in Telecom
September 11*EMEA Time Zone* Technology Primer: DevOps
September 11Technology Primer: OpenStack
View full schedule
I would switch the Subscribers limitation with the Transactions one in the order. My logic is that based on my implementation and benchmarking experience, the HSS is in effect just a small layer of functionality which interfaces through Diameter to a back-end DBMS. I would even say that more than 90% of the resources are then spent in the DBMS then in the HSS delta. Then the capacity is in effect that of the DBMS, which rarely have a problem with the amounts of data required here (tens/hundreds millions of rows) vs. the DB transactions performance.
Then I would even eliminate entirely the Bearers from the list. Bearers are not saved or updated in the HSS, while also the subscriber profile data is supposed to be cached in the MME/PCRF/S-CSCF/etc, not pulled on bearer modifications, rather pushed down on updates.