Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

'Overheid en hulpdiensten waren onvoldoende voorbereid op landelijke 112-uitval'

Nederlandse overheden en hulpdiensten waren onvoldoende voorbereid op een landelijke 112-storing. Dat maakt het Agentschap Telecom bekend in een rapport over de 112-storing in 2019. De communicatie over de storing verliep volgens het rapport 'chaotisch'.

Het Agentschap Telecom publiceerde deze week een rapport over de landelijke 112-storing op 24 juni 2019. Het agentschap publiceerde het rapport in samenwerking met de Inspectie Justitie en Veiligheid, de Inspectie Gezondheidszorg en Jeugd. Volgens het onderzoek verliep communicatie over de storing aan inwoners van Nederland 'chaotisch', zo schrijft het Agentschap Telecom.

Toen bij de instanties duidelijk werd dat 112 met een storing kampte, bleek dat het ministerie van Justitie en Veiligheid en veel van de veiligheidsregio's de gemaakte afspraken betreffende de werkwijze bij het uitvallen van het alarmnummer niet kenden, zo stelt het rapport. Hierdoor moesten de instanties 'veel improviseren', terwijl dit niet nodig was geweest als de organisaties de eerder gemaakte afspraken nader hadden uitgewerkt.

Het gaat hierbij om afspraken die zijn gemaakt na een 112-storing in 2012. Deze afspraken werden vastgelegd in een draaiboek met meerdere mogelijke scenario's. De overheidsinstanties kozen voor 'scenario 4', welke volgens het rapport het beste past bij de storing in kwestie. Overigens gaat dit scenario er vanuit dat het andere noodnummer, 0900-8844, nog wel bereikbaar is. Dat was niet het geval. Hierdoor wachtte het ministerie van Justitie en Veiligheid volgens het rapport te lang met het informeren van de burgers via een NL-Alert-bericht.

Verder voorzagen draaiboeken van zorgorganisaties een landelijke onbereikbaarheid van 112 en een landelijke telefoniestoring niet. De gevolgen hiervan zijn door de onderzochte zorgorganisaties wel opgelost, door het inzetten van alternatieve communicatiemiddelen en extra personeel. Het rapport concludeert daarnaast dat er goed, en met veel vindingrijkheid, is samengewerkt tussen verschillende zorgorganisaties.

Tijdens de landelijke storing zijn drie mensen overleden. Het is onduidelijk of de de vertraagde start van hulpverlening hieraan heeft bijgedragen, stelt het rapport. Wel stellen de betrokken ambulancediensten dat ze binnen de normtijd konden handelen.

De storing voltrok zich door 'een verborgen fout in het routeringsplatform van KPN'. Dit platform bepaalt de 'route' van alle inkomende telefoongesprekken over het netwerk van KPN. Er zijn 'tellers' die het aantal inkomende oproepen bijhouden. Door een software-update zijn deze tellers gelijk gaan lopen, waardoor de systemen gelijktijdig konden uitvallen.

De NL-Alert-storing, die zich ook op 24 juni 2019 voltrok, was niet gerelateerd aan de systeemfout bij KPN. Deze storing zorgde ervoor dat KPN-klanten die gebruikmaakten van 4g tijdelijk geen NL-Alert-meldingen konden ontvangen. Volgens het rapport heeft KPN direct na de storingen maatregelen genomen om herhaling te voorkomen. 'De meeste van deze maatregelen' zijn inmiddels geïmplementeerd, waaronder een aanpassing aan de softwareconfiguratie van de vier routeringssystemen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Daan van Monsjou

Nieuwsposter

25-06-2020 • 15:04

59 Linkedin

Submitter: juliank

Reacties (59)

Wijzig sortering
De storing voltrok zich door 'een verborgen fout in het routeringsplatform van KPN'. Dit platform bepaalt de 'route' van alle inkomende telefoongesprekken over het netwerk van KPN. Er zijn 'tellers' in plaats die het aantal inkomende oproepen bijhouden. Door een software-update zijn deze tellers gelijk gaan lopen, waardoor de systemen gelijktijdig konden uitvallen.
Ik vind dat deze copy-paste uit het nieuwbericht met het vervangen van 'bewegwijzeringssysteem' door 'route' weinig toevoegd aan dit artikel en al helemaal niet duidelijker maakt wat er nu echt mis is gegaan.

Gelukkig gaat het raport er wel iets beter op in:
Directe en achterliggende oorzaken
Het routeringsplatform heeft ten behoeve van managementinformatie meerdere counters, waaronder een counter die het aantal routeringsaanvragen bijhoudt. Bij iedere routeringsaanvraag wordt deze counter met één opgehoogd. Alle vier de routeringssystemen hebben een eigen counter. Op 24 juni 2019 bereikte de eerste counter zijn maximale waarde. De eerstvolgende routeringsaanvraag resulteerde in het negatief worden van de counter waardoor er foutmeldingen werden gegenereerd. Elke nieuwe routeringsaanvraag veroorzaakte een nieuwe foutmelding. De counters van de overige drie routeringssystemen bereikten eveneens hun maximale waarde en veroorzaakten nieuwe foutmeldingen. Elke foutmelding wordt opgeslagen. Door het opslaan van de grote hoeveelheid foutmeldingen in combinatie met de enorme aantallen routeringsaanvragen vanwege herhalingsverkeer, kwam het routeringsplatform na een uur niet meer toe aan het afhandelen van routeringsaanvragen.

[Reactie gewijzigd door aequitas op 25 juni 2020 15:21]

Klinkt als een fout dat iedereen had kunnen gebeuren. Je bouwt een bepaalde appliatie op basis van bepaalde int waardes. Als je over deze int waardes gaat, dan overflowen ze, wat resulteert in negatieve waardes. Een int heeft zowel negatief als positief een maximale waarden. Je zou kunnen kiezen om een unsigned int (of andere waardes, zolang maar unsigned is) gebruiken voor dit soort applicaties. Dan is de positieve waarde groter en is negatieve waardes niet meer mogelijk. Ik denk dat hun applicatie de counters reset als deze opnieuw opgestart wordt, blijkbaar werkte de applicatie zo goed dat het niet nodig was om preventief de applicatie opnieuw op te starten en de counters te resetten.

Meer details:
http://www.cplusplus.com/articles/DE18T05o/
https://stackoverflow.com...235436/c-integer-overflow

[Reactie gewijzigd door Xieoxer op 25 juni 2020 17:37]

Je zou kunnen int64_t gebruiken voor al je ints. Of zelfs uint64_t. En te stoppen met volledig zinloos bits te proberen sparen.

Als ze dan nog overflowen dan ben je bv. > 64 keer tot de tweede macht aan het doen en heb je een nummer dat grotere is dat het totaal aantal moleculen in het zichtbare deel van het universum.
De eerstvolgende routeringsaanvraag resulteerde in het negatief worden van de counter waardoor er foutmeldingen werden gegenereerd.
Sorry, maar ben ik dan de enige die denkt huh? Haal de counter weg en je hebt dus nooit meer een issue? Dit klinkt namelijk als een standaard integer overflow die getriggered wordt doordat er standaard round robin loadbalancing wordt gebruikt. Alle drie de services vallen dan na elkaar om.
Als je het probleem eenmaal weet is de oplossing eenvoudig. Of dat nou 'de counter weghalen' is of 'voorkomen dat ie negatief wordt' of 'zorgen dat het om kan gaan met negatieve waardes' maakt dan natuurlijk niet zo veel uit.

De counter zal ongetwijfeld worden gebruikt om op te acteren. Dan wel direct, dan wel vanuit (management)rapportage oogpunt.

Er zal waarschijnlijk niemand bij stil hebben gestaan dat er een overflow plaats kan (en zal) vinden als het systeem maar lang genoeg draait. Je kunt dan wel stellen 'dat dat nooit had mogen gebeuren' maar voor elk aantal test-scenario's dat je kunt bedenken is er altijd wel weer een alternatief te bedenken... Ik moest denken aan dit stripje over QA wat ook hier weer van toepassing is: https://1.bp.blogspot.com...CLcBGAs/s640/everyone.png
MWah dit is ook een voorbeeld van waarom het mis gaat in een gescheiden development operations wereld. Vanuit development is er nooit bewustzijn geweest hoeveel requests er daadwerkelijk worden gedaan en vanuit operations wordt er niet bij stilgestaan dat dergelijke counters aanwezig kunnen zijn.

Er zijn meerdere oorzaken die kunnen leiden tot dit soort gedrag van applicaties. In 9 van de 10 keer gebeurt het uiteindelijk door gebrek aan communicatie ergens in het proces.

Als je echter weet dat er 10.000 requests per minuut over de lijn komen dan ga je echter niet een counter op basis van een int doen. Dan ben je binnen 450 dagen de sjaak.
Zou een counter niet per definitie unsigned moeten zijn?
Daar ben ik wel vanuit gegaan in het voorbeeld van 450 dagen. (dat is overigens met 3-voudig uitgevoerde service), maar als ie negatief wordt is dat inderdaad wel het geval. Ik weet echter wel dat het in veel talen default signed is.
Vaak worden negative waardes als foutcode gebruikt.
Of afhankelijk van onderhoud door een handvol medewerkers die weg-gereorganiseerd zijn.
Zou niet de eerste keer zijn dat er ergens legacy hardware/software in een cruciaal systeem blijkt te zitten.

Scenario's bedenken is best lollig, maar het blijft speculatief wat er mis is gegaan...
Pikant detail: in het rapport is niet beschreven hoe het kan dat het nummer van de tiplijn van de telegraaf ineens als "alternatief noodnummer" via NL alert verstuurd werd. Daarnaast staat er ook niet hoe het kan dat de rectificatie hiervan bijna 1 uur later kwam.
Het staat er wél in. Het gebeurde 'per abuis'. Een mens maakte een vergissing. Sh*t happens.

Er wordt ook deuidelijk gezegd dat de informatie uit verschillende bronnen kwam en dat dit verbeterpunten zijn die in het draaiboek dienen te komen.

Wat wil je meer? een schandpaal?
Inderdaad, waarschijnlijk simpel copy paste foutje. Persoon die de NL alert wilde verzenden had nog een telegraaf nummer onder de copy staan en verder niet opgelet. Of zo iets. Waar mensen werken worden fouten gemaakt.
Dan kun je je nog afvragen, had die persoon dus eerst ff het nummer van de tiplijn opgezocht?
Is toch prima voor te stellen? Iemand van communicatie krijgt zowel opdracht om het NL alert te schrijven, en tegelijk ook om dit nummer kenbaar te maken bij zoveel mogelijk persredacties, waaronder de telegraaf. Gezien dit nummer op de contactpagina staat onder redactie voor onder andere 'tips over ongelukken' is dat vermoedelijk het nummer welk korte lijntjes met de eindredactie heeft.
Namen en rugnummers!
Welk bedrijf en welke topman was verantwoordelijk voor dit gefaal? Dit zijn fouten die door junior testers uit systemen gehaald worden als dit door junior programmeurs IN het systeem wordt gestopt.
Waarschijnlijk zijn alle procedures keurig gevolgd en overal waar een vinkje moest staan stond deze er ook, maar gezond verstand en goede ontwikkelaars zijn schaars tegenwoordig...

Hoe is het mogelijk dat dit soort knullige fouten in een systeem zitten... Iets in mij zegt dat het te maken heeft met de goedkoopste aanbieder en aanbestedingen (aanname: waarschijnlijk naar een Indiase "strategic partner"...)
Uit de omschrijving @aequitas maak ik op dat het dus feitelijk een overflow is geweest.

Waarschijnlijk is het dan veel onschuldiger. Zat ervaren ontwikkelaars die voor zo'n counter dan een long zouden gebruiken, en dan denken, die max waarde, daar komen we toch nooit aan. (famous last words)

Wellicht wordt er vervolgens nog een inschatting gemaakt wat er kan gebeuren als het mis gaat: "Ow is alleen maar logging, zo'n impact zal dat niet hebben".

Zo gaan die dingen. Overal.

Dit soort problemen zijn ontzettend subtiel, en komen op heel veel plekken voor. En hoe groter het pakket hoe moeilijker het wordt om te voorspellen hoe een systeem zal reageren als zo'n overflow optreed. Laat staan dat daar over nagedacht wordt jaren nadat zo'n counter geintroduceerd is (waarom? het werkt al jaren perfect).
"fouten die door junior testers uit systemen gehaald worden" Laat me niet lachen.
"Ow, dit is alleen tijdelijk, na het testen kan het er uit."
Ik denk dat je niet zo kort door de bocht kunt concluderen dat dit een "knullige" fout is. First of all zijn de omschrijvingen uiteraard extreem versimpeld en niet representatief voor de werkelijke omvang van zo een systeem.

Het zou best kunnen zijn dat deze fout enkel ontstond als een zeer ongebruikelijke combinatie van factoren zich voordeed. Uiteraard kun je daarvoor integratie testen schrijven, maar als je te maken hebt met condities die 4 abstractie lagen dieper in de code voor problemen zorgen is het heel lastig om daar tegen op te boksen.
hound is ook weer zo iemand die beter als duurbetaalde consultant* aan de slag kan gaan. De meeste organisaties zullen een hoop geld overhebben voor jouw kennis en kunde om dingen vlekkeloos te laten verlopen.

Al kan het ook zijn dat jij nooit iets doet waardoor je nooit fouten maakt.

*) Na nog een keer lezen van jouw bijdrage moet ik echter concluderen dat jij totaal alle eigenschappen mist om consultant te worden. Je trekt immers al conclusies voordat je de feiten kent.
Daarbij moet een cultuur voorkomen dat wanneer iemand een fout maakt deze geschoren en gevild wordt. Wat dat betreft kunnen we veel leren uit de luchtvaart.
Wat ik niet begrijp is waarom al het 112 verkeer verplicht lang KPN moet. Er zijn minimaal 3 grote telefonie aanbieders in Nederland en daarnaast nog een aantal serieuze kleinere. Waarom laten we deze partijen niet rechtstreeks koppelen met 112. Theoretisch gezien zou dan een uitval bij KPN niet tot volledige uitval van 112 moeten leiden. Je kunt dan altijd nog op zoek naar een VodafoneZiggo of T-Mobile verbinding.
112 dienst is aanbesteed. Dat is verplicht omdat het een bepaalde geldwaarde heeft en de overheid die niet onderhands mag gunnen. Technisch is dit met meerdere providers natuurlijk stukken onafhankelijker te maken, maar zo werkt de marktwerking niet. Als er geen concurrentie is kunnen ze allemaal maar wat vragen. Nu telt de laagste prijs richting de overheid, zolang je aan bepaalde eisen voldoet. En zelfs als je er al aan voldoet kan het nog steeds fout gaan blijkt nu.
Nee, Ik weet best veel van aanbesteden. In 1999 als stageopdracht een handleiding Europees Aanbesteden voor een grote ICT afdeling geschreven. Daarna meermalen direct of indirect betrokken geweest bij aanbestedingen. Dit is geen reden. Je kunt best kiezen om interconnectie los te maken van het beheer van het platform.

De aanbesteding zou dan zijn voor een beheerder van een 112 platform met interconnecties naar de 5 grootste telefonie aanbieders in de Nederlandse markt. 112 heeft om wat voor reden dan ook de interconnectie en het beheer van het platform gelijkgesteld. Er is niets in de procedures voor Europees aanbesteden die dat verplicht stelt.
Ik denk dat het simpelweg met "geld" te maken heeft. Inderdaad verbied niemand je om dit soort eisen in de aanbesteding te zetten, maar dan heb je ineens een contract met 3 partijen die allemaal geld willen verdienen. Jij zet in je bestek van eisen een minimale uptime en zolang je daaraan voldoet is het gewoon klaar. En dat zal goedkoper uitpakken dan een constructie waar elke telco in NL een oprit naar 112 kan zijn. En de aanbestedingsregels geven de aanbieder met de laagste prijs het contract. Zo simpel is dat dan wel weer.

En commercieel gezien, als je je contractueel overeengekomen performance niet haalt, betaal je een boete. Dus flauw geredeneerd, als je van 99.9% naar 99.99% wil qua gegarandeerde uptime en dat kost een miljoen op jaarbasis, kan het attractiever zijn om een boete te incasseren van - zeg - een paar ton. Als dat minder dan 5 keer per jaar gebeurt maak je daar zelfs winst op. En ja, dat is ethisch niet gaaf, maar dat werkt het aanbesteden wel in de hand. En de overheid maakt ook keuzes in de gewenst uptime. Ik vermoed dat - gekeken naar de laatste 15 jaar - de gemiddelde uptime prima gehaald zal zijn. Dan is er op papier althans geen probleem.
Ik gok dat dit historische legacy redenen heeft van toen KPN nog PTT Telekom was en een staatsbedrijf was. Toen was KPN de enige telecomprovider en ik gok dat men iets had van "if it aint broke don't fix it" Want natuurlijk wil je niet de persoon zijn die "zomaar" en "zonder reden" zulke grote wijzigingen door voert want als er iets mis gaat met 112 ben je de sjaak.
Over legacy gesproken: werkt 06-11 eigenlijk nog?
Dat denk ik niet, ik had jaren geleden een mobiel telefoonnummer dat begon met 06 - 11.
Kan dat niet samen?
Allereerst: het is niet verplicht dat dit via KPN moet. Het had ook een andere provider kunnen zijn - en ook daar had een dergelijk probleem op kunnen treden.

Daarnaast: realiseer je wel dat het introduceren van een tweede provider enorm veel extra complexiteit introduceert. Er moet onderling gerouteerd worden, al het testwerk moet dubbel uitgevoerd worden, alle afnemende systemen moeten met meerdere providers om kunnen gaan, de technische mogelijkheden van beide platformen (denk aan positiebepaling) moeten gelijk lopen én gelijk werken, de kosten gaan minimaal verdubbelen, enzovoorts. Redundantie van dit soort complexe systemen is - complex.
Wat wel makkelijk had gekund, 112 en 0900-8844 aanbestedingen niet aan dezelfde provider gunnen. Nu was ook de backup weg. Alle providers moeten naar KPN routeren en die routeert naar de politie. Slecht idee, gewoon grote providers rechtstreeks 112 inkoppelen.
Voor het 112 nummer lijkt me dat de moeite waard. Ik kan me geen belangrijker telefoonnummer voorstellen namelijk.
Er zijn al verschillende koppelingen. Daarom kan je via een willekeurig telefoonnetwerk naar 112 bellen. Waar wil je de koppeling dan liever hebben en waarom denk je dat het kan en beter zou zijn? Per provider een aparte telefoon bij een meldkamer? Per provider een eigen netwerkaansluiting bij een meldkamer? Per provider een aparte koppeling met de netwerkproviders van een meldkamer? Per provider een provider een koppeling met de netwerkservices voor een meldkamer?
Er is een meldkamer, bij de voordeur staat een switch, daarachter een telefoonplatform. Op de switch komt een kabel binnen van KPN, een kabel van Ziggo en een kabel van T-Mobile. Eventueel maak je daar een gedistribueerd netwerk van met meerdere gedeelde platformen en management over verschillende fysieke locaties.

Op dit moment lijkt het zo te werken dat iedereen een interconnect met transit naar KPN moet kopen om een verbinding naar 112 te krijgen. Dat betekent dat wat er ook gebeurd al het 112 verkeer eerst naar KPN moet en dan pas bij 112 aankomt. Hoogst waarschijnlijk betekent het ook dat onder het platform alleen maar KPN verbindingen zitten met KPN routeringen etc. Het is op ieder laag van de OSI-stack KPN.

Het effect is dat een fout in KPN transit leidt tot uitval van 112. Een fout in KPN glasvezel leidt tot uitval van 112. Mijn punt is dat je moet gaan identificeren of de totale afhankelijkheid van KPN wel slim is. Mijns inziens, maar misschien heb ik het fout, zou je KPN transit en netwerken uit de stack moeten kunnen halen. Als je dat doet dan KPN transit of glasvezel uitvallen en dan nog doet een deel van 112 het.
Hoe is dat geen goed idee?
Dat is (wat ik uit berichten in het nieuws verneem) omdat KPN in nederlandse handen en een buitenlandse partij daardoor de overheid niet onderdruk kan zetten met hogere prijzen of een lagere prio in het oplossen van storingen wanneer die zich voordoen.

Vodafone en T-mobiel zijn immers buitenlandse bedrijven in handen van buitenlandse partijen.

[Reactie gewijzigd door Usul_Atreides op 25 juni 2020 15:38]

Het zijn allen beursgenoteerde bedrijven met winstoogmerk. KPN is door de regering eerder geprivatiseerd. En dan ben je je recht van spreken simpelweg kwijt als regering, je bent er niet de baas meer van. Dat is de theorie. Ik ga er van uit dat bij calamiteiten er wel een lijntje tussen het Catshuis en het hoofdkantoor van KPN zal lopen om wat dingen te fixen.

112 Zal ook netjes uitbesteed zijn verwacht ik conform de EU regels, al kan ik daar niks over terugvinden. Wel dat Tele2 de overheidstelefonie doet, maar ik lees nergens dat 112 daar ook bij zit.
Van de NS bijvoorbeeld is de overheid groot aandeelhouder, dus er kan zelfs nog strategische zeggenschap zijn, bij een geprivatiseerd bedrijf.

[Reactie gewijzigd door Knetterkaars op 25 juni 2020 23:28]

Zeker, maar de overheid is geen grootaandeelhouder meer van KPN en er is ook geen "gouden aandeel" meer. Dus strategisch zeggenschap over KPN is geen optie in dit geval ...
Dat een CEO niet Nederlands is maakt niet dat het betreffende bedrijf dan niet meer Nederlands is.
"Wel stellen de betrokken ambulancediensten dat ze binnen de normtijd konden handelen."

Ja, want de gesprekken kwamen niet of later binnen, dus dit zegt precies helemaal niks lijkt mij.

Sterker nog als ze daar alle telefoons uitzetten zien die KPI's er vast schitterend uit. Geen enkele rit te laat!
De onzin van statistieken goed uitgelegd ^^


"4 op de 5 heeft 4 anderen om zich heen"
'k Zie net de KPN reactie op hun eigen pagina ...
Ik persoonlijk vind het bizar dat er gesteld wordt dat de Overheid en hulpdiensten onvoldoende waren voorbereid op de landelijke 112-uitval. We hebben het over 112 en niet over de helpdesks van ZIGGO. Hier zou op zijn minst een "hot standby" moeten zijn.

edit: foutjes.

[Reactie gewijzigd door frankhan op 25 juni 2020 16:33]

Ik vind het vooral bizar omdat er hier elke keer diverse tweakers zijn die roepen dat je je hier niet op kúnt voorbereiden, maar dit rapport zegt dat dat dus wél kan.
Maar als er een systeem wordt gebouwd dat zo redundant is dat er niets fout kan gaan, wordt de overheid ook weer aan de schandpaal genageld omdat het allemaal zo duur wordt, en dat "van onze belastingcenten".

Ook de overheid kan geld maar 1 keer uitgeven dus iedereen die vindt dat 112 beter moet, moet dan ook maar aangeven waar op bezuinigd moet worden.
Ik ben het er heus wel mee eens dat niet alles zo duur moet zijn van onze belastingcenten, maar bepaalde dingen, zoals 112-redundantie, mogen wat mij betreft wel wat extra's kosten.
Hoe valt je antwoord dat het best meer mag kosten dan samen een redundantie die nog acceptabel is? Andere redundantie is ook niet ultiem redundant.
De politie zelf krijgt 4,4 miljard aldus de huidige begroting. De hele culturele sector krijgt 400 miljoen.

Volgens mij heeft de politie nog wel wat geld over ;)
Zelfs het meest redundante systeem kan plat gaan. Alles kan stuk. De keerzijde van een nog ingewikkeldere redundant netwerk is dat niemand het op een gegeven moment meer snapt en als er dan een keer iets fout gaat er echt een groot probleem is. Je kunt beter iets minder redundant zijn maar iets maken dat relateif makkelijk weer te repareren is.
Was dit die keer toen het nummer van de telegraaf werd gecommuniceerd? Of zoiets?
Maarja de vraag blijft is het 'waren' of 'zijn' niet goed voorbereid.
Met de overheid en IT weet je het immers nooit.
Toch zijn er op dit forum best wel veel mensen die er van dromen als alle infrastructuur weer in overheidshanden komt....
Het verbaast me elke keer weer dat "we" van alles vinden, maar gemakshalve vergeten dat alle Telco's gewoon bedrijven zijn met winstoogmerk. Die leveren wat ze beloofd hebben - of doen hun best daarvoor - en dat is het dan. En dat is ook gelijk de reden dat glasuitrol in NL gewoon zwaar ondermaats is. De investeringen zijn immens, "wij" vinden dat die bedrijven "moeten" investeren voor ons.

Maar waarom moeten ze dat dan? Ze zijn ons niets verplicht. Als ze al iets verplicht zijn, is dat naar de aandeelhouders toe. Die impasse doorbreken zou inderdaad een aardige zijn om de infrastructuur (expliciet NIET de diensten) naar de overheid terug te halen. Ik heb eerder berekend dat dat circa 20miljard gaat kosten, gemiddeld 2750 euro per huisdeur. En dan mag je nog glas gaan uitrollen wat nog eens 15-20 miljard kost. Dat geld heeft de regering domweg niet. Als we dit graag willen, mogen we dus samen die 4000-5000 euro per gezin ophoesten en kunnen we deze discussie achter ons laten.

My two cents? Dit gaat nooit gebeuren. Vergeet het maar. Wishfull thinking. De regering zou iets in de 5G eisen kunnen zetten dat er verplicht een data abo moet komen van x euro, dat zou wellicht een uitweg kunnen zijn.
Zoveel geleerde mensen in NL en zoveel bestuurders maar geen 1 die vooruit kan bedenken wat doen we als 112 plat gaat? Sorry al deze mensen in deze ketens -1
Jij kan het blijkbaar wel. Wat doe je er aan om dit systeem beter te maken? Of ben je stuurman aan wal?

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True