Our video tutorials are only available for viewing at our website with an internet connection (no offline option).
Public Course Schedule
October 17Technology Primer: Orchestration
October 18Technology Primer: DevOps
October 18Technology Primer: Artificial Intelligence (AI)
October 19Technology Primer: Blockchains
October 30*EMEA Time Zone* Technology Primer: 5G Services and Network Architecture
November 5Technology Primer: Immersive Technologies
November 13*EMEA Time Zone* Technology Primer: 5G Radio Technologies and Deployments
November 13Technology Primer: Multi-Access Edge Computing (MEC)
November 14Technology Primer: LTE-M and NB-IoT
November 15Technology Primer: 5G Radio Technologies and Deployments
November 15Technology Primer: Licensed Assisted Access (LAA)
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.