Shivkranti Internet Service Pvt Ltd makes a local connectivity bill depend on upstream routes and field repair

Summary

• Shivkranti Internet Service Pvt Ltd is not just a name in a routing table. The Indian Department of Telecommunications' 28 February 2026 licence list records Shivkranti Internet Services Pvt Ltd as a Category B Mumbai internet-service licensee, and APNIC RDAP records AS149195, SHIVKRANT-AS-IN, as active for Shivkranti Internet Service Pvt Ltd.
• The company should be treated as a Mumbai-local ISP, not a national infrastructure operator. Its customer portal says Shivkranti Internet Services operates currently only in Mumbai, while DoT's licence list gives the service area as Mumbai and the public APNIC contacts are in Goregaon West.
• The public operating scale is small. TRAI's June 2025 performance report lists Shivkranti Internet Services Pvt. Ltd. with 214 broadband subscribers and no narrowband subscribers, even as India's national broadband base was above one billion by March 2026.
• The routed network is live but narrow. BGP views show two originated IPv4 /24s, no visible IPv6, 512 IPv4 addresses, valid RPKI status for both /24s and two observed IPv4 upstreams: Vortex Netsol Private Limited and Gigaline Teleservices Opc Private Limited.
• The final network evidence grade is Weak. Public records establish a licensed and routed local broadband operator, but they do not verify last-mile medium, pole or building access, ring topology, physical upstream separation, transit contracts, backup-power runtime, spare stock, field-crew depth, congestion headroom or measured restoration performance.

The company exists at three public surfaces

Shivkranti Internet Service Pvt Ltd has a thin public presence, but the pieces that are visible line up. The strongest licensing evidence is the Indian Department of Telecommunications' UL ISP and UL ISP VNO list as on 28 February 2026. In that list, Shivkranti Internet Services Pvt Ltd appears as licence DS-11/275/2018-DS-III, Category B, service area Mumbai, with Sunil Rajaram Pandey as the authorized person, a Goregaon West registered-office address and an 18 December 2018 signing and effective date. That record does not describe the live network. It does something more basic: it places the company inside the Indian telecom licensing perimeter and ties the licence to Mumbai.

The company's own customer portal at shivkrantiinternet.in gives the second surface. It is not an investor-style corporate site. It is a login-and-payment page with account access, terms, cancellation and contact sections. Its about text says Shivkranti Internet Services is an ISP operating currently only in Mumbai and describes the company as one of the significant players in the city. It also says the service is delivered through "Select entrepreneurs" who follow company standards and that thousands of clients rely on it for business-critical needs. Those are first-party claims, not audited operating metrics, but they match the licensed-city framing and explain why the company may look more like a neighbourhood broadband operator than a large branded carrier.

The third surface is the internet-number record. APNIC RDAP for AS149195 identifies the autonomous system as SHIVKRANT-AS-IN, active, country IN, with the description Shivkranti Internet Service Pvt Ltd. The same RDAP object records registration in December 2021 and a last-change event in September 2025. APNIC RDAP for 103.178.48.0/23 identifies the active portable IPv4 allocation as SHIVKRANT and describes it as SHIVKRANTI INTERNET SERVICE PVT LTD. Both RDAP objects point to a Goregaon West operational address for network and abuse contacts.

Those three views do not give the same kind of evidence. The DoT list proves licence status and service-area scope as of the list date. The customer portal proves that the company presents a subscriber-facing payment and support channel and says it operates in Mumbai. APNIC proves that it holds an active ASN and an active IPv4 allocation. Together they are enough to write about a real local broadband operator. They are not enough to treat the operation as a resilient network with known physical paths.

That distinction is the first guardrail for reading Shivkranti. A company can have a licence and an ASN while buying much of its connectivity from upstream providers, using third-party ducts, sharing poles or buildings, or relying on local distribution entrepreneurs for the final access segment. It can also be useful to customers precisely because it is small and local. The evidence supports the identity floor. It does not disclose the operating architecture above that floor.

Mumbai is the operating geography, not a general Indian footprint

The planned category for this company is regional ISP. For Shivkranti, that category is defensible only if "regional" is read tightly. The DoT eServices ISP page explains the general licensing logic: ISP licences are for companies that provide internet access services to households, enterprises and other users, and the page says categories are tied to coverage area. The same page describes ISP delivery technologies broadly, including fibre optics, DSL and wireless broadband. But those are general service examples. They are not Shivkranti-specific disclosures.

The actual Shivkranti row in the February 2026 DoT list gives the service area as Mumbai. The company's own portal narrows the reader's expectations even further by saying it operates currently only in Mumbai. APNIC's network address record and ASN record both use Goregaon West contact information. The related addresses on the portal point to Goregaon West and Motilal Nagar. None of that proves exact coverage inside Mumbai. It simply makes the safe editorial frame much smaller than "India ISP."

That localness matters because a Mumbai broadband bill is physically local long before it becomes a BGP route. A customer in a building or small business gets usable internet only when the access plant reaches the premises, the customer device is powered, the building path remains intact, the local aggregation point is up, and the upstream links continue to carry traffic out of the city access footprint. If the ISP uses fibre for some streets, cable plant for others, wireless drops in particular blocks, or distribution partners in specific neighbourhoods, each medium has a different break pattern. Public evidence does not identify which medium Shivkranti uses at which address.

DoT's internet-service page is useful as a technology menu because it names fibre, DSL and wireless broadband as ISP access technologies. It should not be stretched into a Shivkranti technology map. The Shivkranti portal does not publish a fibre-route map, a cable-network description, a tower list, a wireless frequency plan, a building list, a serviceability checker, a speed-tier table or a network operations report. It does publish customer login and payment functions, refund terms, contact numbers and a service narrative. The public story is operational presence, not network transparency.

That makes the company's service area a hypothesis that can be tested only address by address. Mumbai is the licensed area. Goregaon West is the visible operating centre. TRAI's provider table gives a small subscriber count. The article can therefore discuss Mumbai-local resilience and the economics of a small operator. It cannot claim citywide coverage, deep metro fibre, independent towers or redundant neighbourhood rings.

The subscriber table forces the downgrade

The sharpest scale evidence comes from TRAI. In its quarterly performance indicators report released in September 2025, the provider table for internet subscribers lists Shivkranti Internet Services Pvt. Ltd. with 214 broadband subscribers, zero narrowband subscribers and 214 total subscribers as of the June 2025 quarter. That is not a typo in a marketing claim; it sits in a regulatory performance report. It may lag later growth or reflect reporting classifications that exclude reseller relationships, partner-billed users or other non-mass-market arrangements. But it is still the best public subscriber number found in the current pass.

The contrast with the national market is severe. The Press Information Bureau's summary of TRAI's March 2026 quarter says India had 1,065.88 million broadband subscribers, 46.54 million fixed wired access internet subscribers and 56,222 public Wi-Fi hotspots. That national scale does not make Shivkranti unimportant to its actual users. It does mean that a 214-subscriber provider should not be analyzed as if it has the capital base, staffing redundancy or public-reporting burden of a national access network.

Small can be resilient in some local ways. A small ISP can know buildings, technicians, landlords and troubled cable paths better than a distant call centre. The decision loop can be short, the service area compact and the founder or engineer close to the fault. A customer portal that lists direct phone and email contacts may be more practical for a small building than a large operator's ticket queue. Shivkranti's portal claim that it works through select entrepreneurs is consistent with a local-distribution arrangement in which relationships, not only ducts and routers, are part of the operating system.

Small can also be fragile. A local operator with hundreds of subscribers may have fewer spare routers, fewer vehicles, less inventory, a thinner night or monsoon response plan and less leverage with upstream carriers. A single trusted technician can be a strength until that person is unavailable. A single building-access route can be cheap until a property manager changes locks or a riser is damaged. A single power feed can be adequate until a local outage outlasts the battery in the distribution point. The public record does not let the reader choose confidently between these possibilities.

TRAI's same March 2026 summary reports wireline quality benchmarks such as provisioning within seven working days, fault incidences per 100 subscribers and point-of-interconnection congestion. These national benchmark categories are useful because they describe the questions a broadband operator has to answer: how fast service is provisioned, how often faults occur, whether interconnection congests and how quickly complaints are resolved. They do not supply Shivkranti-specific performance. The safe interpretation is that Shivkranti is within a regulated service class, while public records do not reveal its own provisioning interval, fault rate, complaint performance or busy-hour throughput.

That is why the operating-status hypothesis becomes a downgrade rather than a rejection. The public evidence does not say the company is dormant. It says the company is licensed, customer-facing, routed and small. The article therefore should not abandon the regional-ISP thesis; it should narrow it to a Mumbai micro-ISP and grade network evidence as Weak.

AS149195 is live, but it is a narrow edge

The public internet edge is clear enough to identify. Hurricane Electric's BGP Toolkit page for AS149195 identifies Shivkranti Internet Service Pvt Ltd, India origin, two originated IPv4 prefixes, two announced IPv4 prefixes, no originated or announced IPv6 prefixes, 512 originated IPv4 addresses, no RPKI-invalid originated routes in its current summary and two observed IPv4 peers. BGP.tools for AS149195 similarly classifies the network as active under APNIC, gives it an eyeball-network role, lists two IPv4 /24s and shows two upstreams: AS137633 Gigaline Teleservices Opc Private Limited and AS136334 Vortex Netsol Private Limited.

RIPEstat adds useful time and validation evidence. The AS overview endpoint returns SHIVKRANT-AS-IN - Shivkranti Internet Service Pvt Ltd and marks the ASN as announced. The announced-prefixes endpoint shows 103.178.48.0/24 and 103.178.49.0/24 during the current two-week observation window. The routing-status endpoint shows two IPv4 prefixes, 512 IPv4 addresses, two observed neighbours and high RIS visibility at the query time. RPKI validation for 103.178.48.0/24 and RPKI validation for 103.178.49.0/24 both return valid status against a route-origin authorization for 103.178.48.0/23 with max length /24.

CAIDA's ASRank API for AS149195 gives the same small-network shape from a different public dataset: one-AS customer cone, two prefixes, 512 addresses and two providers. That view is not a contract record, but it reinforces the point that the public internet edge is compact and provider-dependent.

That is good hygiene for a small routed ISP. It means the prefixes are not merely stale registry entries; public collectors currently see them, and origin validation is in place for the two /24s. It also means the network is compact. Two /24s equal 512 IPv4 addresses before network, broadcast, infrastructure and assignment practices are considered. Carrier-grade NAT, private addressing and dynamic allocation can support more subscribers than public addresses one-to-one, and the TRAI number does not require a large public address pool. But the small prefix set leaves limited public evidence of scale and no visible IPv6 deployment.

The absence of visible IPv6 is not automatically a service failure. Many small broadband networks still operate customer access primarily through IPv4 plus NAT. It does, however, matter for future-proofing and transparency. If an operator has no public IPv6 route, customers cannot be inferred to receive native IPv6 connectivity from global BGP evidence. That may affect application reachability, inbound service hosting, troubleshooting and long-term address pressure. A stronger public record would show IPv6 allocation, route origination, RPKI status and customer-facing support for IPv6 on the operator site.

The two observed upstreams also need calibration. They improve the picture compared with a single observed provider. If one upstream path fails logically, the other may keep AS149195 reachable if routing policy, capacity and physical handoff are configured for failover. But public BGP does not show whether those upstream circuits enter different buildings, cross different ducts, use different optical paths, terminate on separate routers or have enough spare capacity under stress. A logical neighbour list is not a trench map.

That is especially important in a compact geography. APNIC RDAP for Vortex Netsol, AS136334, places that upstream's contact surface in Goregaon West. APNIC RDAP for Gigaline, AS137633, places Gigaline's contact surface in Parbhani, Maharashtra. The difference in corporate address does not prove route diversity. The Shivkranti handoffs could still share ducts, aggregation buildings, power dependencies or intermediary carriers. The public view proves observed upstream diversity at the AS level. It does not prove physical diversity.

There is one more route-policy clue. APNIC whois for the 103.178.48.0/24 and 103.178.49.0/24 routes includes origin objects for AS149195 and also for AS134014, NET 4 U SERVICES PVT LTD. The current BGP pages emphasize AS149195's observed origination, while the route objects show that the prefix policy has allowed another Mumbai-area ASN as an origin in registry data. That may reflect historical upstream support, backup arrangements, route-object maintenance or a transit configuration that is not visible as current origination. It is not a finding of misrouting. It is another reason to avoid pretending the public record exposes the complete edge design.

No PeeringDB record means no public interconnection map

PeeringDB is not mandatory for an ISP. A small local access network can operate entirely through paid transit or private upstream arrangements and have no reason to publish an exchange profile. Still, the PeeringDB API query for ASN 149195 returns no network entity. That negative result has analytical value. It means there is no participant-maintained PeeringDB profile describing facility presence, internet exchanges, public peering policy, traffic volume range or contact role.

For larger operators, PeeringDB can help distinguish an internet edge with direct exchange participation from a customer cone that simply buys transit. For Shivkranti, public evidence points to the latter or at least to an undisclosed interconnection arrangement. The visible paths are upstream AS relationships observed by BGP collectors, not public exchange ports. The article therefore cannot say Shivkranti peers at a Mumbai IX, has local cache relationships, maintains direct content-provider interconnects or carries traffic over a named colocation site.

That absence also affects congestion analysis. Customers experience congestion at the narrowest point in the path: the local access segment, a building switch, a neighbourhood aggregation link, an upstream handoff, a transit circuit, a peering route or a remote content path. BGP tells us only that AS149195 has global reachability through observed neighbours. It does not reveal traffic volumes, port speeds, contention ratios, evening utilization, packet loss, latency to major content networks or what happens when one upstream is withdrawn.

For a 214-subscriber operator, congestion could be either modest or acute. A small user base reduces aggregate demand, but a very small upstream circuit, oversubscribed distribution segment or single busy building can still degrade service. Conversely, a modestly provisioned upstream could be more than enough if the customers are concentrated and usage is light. No public traffic statistics settle the point. The honest article has to frame capacity as installed versus usable: an ASN and two /24s are installed routing resources; usable customer experience depends on access and backhaul capacity that is not publicly disclosed.

This is where a small operator's economics and reliability become the same question. If the business succeeds by keeping bills low, it must hold down the cost of customer acquisition, access build, upstream bandwidth, support and field repair. That can encourage careful reuse of local infrastructure and close relationships with buildings. It can also leave little margin for duplicate upstreams, spare hardware, standby crews and long-duration backup power. Without published tariffs, network diagrams or audited subscriber economics, the article can identify the tradeoff but cannot score it.

The last mile is the missing evidence

The assignment's physical dependency list includes access plant, poles or towers, upstream transit, field crews, customer-premises equipment and local power. For Shivkranti, the last mile is the least disclosed part of the public record. The company site says it provides affordable broadband access to home users and corporates in Mumbai. It does not say whether a particular customer is reached by fibre, coaxial cable, Ethernet over building wiring, fixed wireless, leased last-mile capacity or a partner-managed drop.

That missing map is not a cosmetic problem. Access medium determines failure mode. Fibre can be cut by road work, damaged in a building riser, bent in a patch box or disconnected by a contractor. Coaxial or Ethernet distribution can fail through water ingress, connector corrosion, switch power loss or building rewiring. Fixed wireless can fail through line-of-sight obstruction, antenna misalignment, interference, power loss or unsafe roof access. A partner distribution network can fail because the partner's spares, technicians or permissions are not the ISP's own.

India's infrastructure-protection machinery underscores that buried and overhead facilities are vulnerable. The government's Call Before u Dig portal describes itself as a Department of Telecommunications initiative to reduce damage to underground assets by coordinating digging agencies and utility owners. The DoT eServices navigation also places Right of Way and Call Before u Dig alongside industry services. Those programmes are not Shivkranti-specific evidence. They show why a local ISP's physical route cannot be hand-waved away. A single uncoordinated excavation or building job can matter more to a small access network than to a carrier with multiple protected rings.

The company portal's "Select entrepreneurs" language is also important. It suggests that at least part of service delivery may rely on local distribution actors or field partners who follow Shivkranti standards. That can improve neighbourhood reach: entrepreneurs know buildings, residents, managers and practical installation routes. It can also complicate accountability: the subscriber buys service from the company, but the fault may sit with a partner cable, an access switch, a rooftop device, customer-premises equipment or upstream bandwidth. The public record does not explain where the demarcation sits.

Customer-premises equipment is another blind spot. The portal lets users log in by mobile number, username or account ID and pay bills. It does not publish router standards, optical-network-terminal device types, wireless CPE requirements, service-level commitments or customer-owned-device policies. When an access network is small, the home router or building switch may be the most common failure point. But without support documentation, a reader cannot tell whether Shivkranti remotely monitors customer equipment, stocks replacement CPE, separates Wi-Fi complaints from line faults or publishes maintenance advisories.

Local power is equally opaque. The access path needs power at customer premises, any building distribution equipment, any active street cabinet or wireless relay, the operator aggregation point and upstream handoff locations. CISA's communications dependency primer is written for critical-infrastructure planning rather than Mumbai consumer broadband, but the dependency logic is general: communications rely on electricity, information technology and transport. A small ISP can keep a core router on a UPS and still lose customers if building switches or access radios have no backup. The public Shivkranti record does not disclose backup runtime anywhere in the access path.

Backup-power design is not just a yes-or-no claim. CISA's Emergency Communications Systems Value Analysis Guide distinguishes batteries, generators, testing and lifecycle choices; those categories are useful for judging any access network that depends on powered distribution points. No public Shivkranti source says which of those measures exists at customer buildings, aggregation points or upstream handoffs.

This is why the article's title focuses on routes and field repair. A local connectivity bill looks like a monthly charge, but it is really a promise that many physical and operational dependencies will keep lining up: licence, route origination, address space, upstream reach, access plant, building permission, power, CPE and a person who can reach the fault. Shivkranti's public materials establish the promise. They do not expose enough of the machinery to grade its resilience strongly.

Field repair is the real capacity reserve

For a very small ISP, field repair can be more decisive than headline bandwidth. A large operator may absorb a failed customer drop through a ticket queue and a multi-shift workforce. A local operator may restore service faster because the field person knows the exact lane, building, society office, cable path and recurring fault. The same localness becomes risk if one technician, one partner or one upstream contact is unavailable.

Shivkranti's portal does not publish staff size or support hours. It provides phone and email contacts, payment terms and a customer-login flow. APNIC's AS149195 RDAP record identifies a NOC director role and abuse contact surface. The DoT licence list identifies an authorized person. Those are responsible contact surfaces, not a workforce plan. They tell a reader who is publicly associated with the network. They do not tell how many people can climb, splice, configure, replace or dispatch.

The "Select entrepreneurs" phrase on the company site matters because it hints at a labour structure in which service delivery is distributed. If those entrepreneurs hold customer relationships and perhaps manage pieces of the access plant, they are part of the network's resilience. Their availability, training, stock, escalation path and authority to touch equipment decide how quickly a fault is repaired. The public record does not say whether each entrepreneur is a franchisee, contractor, reseller, cable operator or local support partner. It only says they follow company standards.

That is enough to create the right questions. Are partner drops documented centrally? Does Shivkranti know which customers sit behind each partner switch or cable? Are spares held by the company, the entrepreneur, or both? Can an after-hours technician enter the building? Are faults triaged by phone, router telemetry, upstream BGP alarms or customer WhatsApp messages? Does the company separate "internet down" into CPE failure, building distribution failure, upstream loss and billing suspension? None of those answers is public.

TRAI's performance framework shows why these questions are not academic. The March 2026 PIB summary of TRAI data lists wireline service benchmarks for provisioning after payment, fault incidences per 100 subscribers and point-of-interconnection congestion. TRAI's own Quality of Service page and its historical broadband QoS regulations supply the regulatory vocabulary for provisioning, repair and reporting. Those categories map exactly to a small ISP's pain points. A local operator with 214 reported subscribers may be able to know every major building; it may also have little statistical buffer if a handful of faults occur in one quarter. A single outage affecting a multi-customer building can look like an operational crisis even when the national table barely notices.

The recovery task is therefore practical. Verify not only upstream diversity but also field-labour diversity. A backup transit route is useful if a router fails, but it does not repair a severed drop cable. A spare optical module is useful if someone can identify and reach the failed device. A second provider relationship is useful if the primary upstream outage is logical, but not if both handoffs depend on the same local power or building. The public evidence supports the need for those checks; it does not show the checks have been passed.

The upstreams are visible, their physical separation is not

The two observed upstreams deserve a close but limited reading. BGP.tools and Hurricane Electric both show Vortex Netsol Private Limited and Gigaline Teleservices Opc Private Limited as visible IPv4 neighbours for AS149195. APNIC RDAP for AS136334 identifies Vortex Netsol Private Limited as an active Indian ASN registered in 2017. APNIC RDAP for AS137633 identifies Gigaline Teleservices Opc Private Limited as an active Indian ASN registered in 2018, although CAIDA's current ASRank API did not show a live degree for Gigaline at the moment queried. BGP collector visibility and registry data are enough to show that AS149195 is not seen behind only one upstream in the current public route views.

The upstream pair still does not prove a protected edge. If both upstreams are delivered over one local fibre provider, one pole run, one building riser, one cabinet, one router or one power supply, a single physical event can remove both. If the backup upstream is small, misconfigured or heavily deprioritized, failover can preserve reachability while making service slow enough for customers to consider it down. If the backup route has not been tested under load, the existence of a BGP session may be more comforting on a diagram than in an outage.

CISA's public-safety communications resiliency guide makes a general point that applies here even outside the public-safety context: apparently separate communications services can share central offices, points of presence, conduits or physical routes. The lesson is not that Shivkranti has a hidden common-mode failure. The lesson is that public AS-path diversity is only the beginning of a diversity audit.

The local geography increases the need for caution. Shivkranti's APNIC contacts are in Goregaon West. Vortex's APNIC contact surface is also in Goregaon West. NET 4 U Services, whose AS134014 appears in route objects for the Shivkranti prefixes, is in Malad West. These nearby addresses may reflect a practical west-Mumbai ecosystem of small ISPs and upstreams. That can be operationally useful: local providers can coordinate quickly, know the same ducts and exchange capacity nearby. It can also concentrate risk if the relevant paths depend on the same local infrastructure.

Gigaline's APNIC contact surface is in Parbhani, which may suggest a more distant provider relationship, but a registered office location is not a circuit path. The route could still be sold through intermediaries or delivered at a Mumbai handoff. Public BGP does not reveal the physical handoff. A serious resilience review would ask for circuit IDs, meet-me-room locations, demarcation points, provider letters, path diversity statements, traceroutes, test-failover logs and busy-hour utilization graphs.

Absent that evidence, the right grade is not "no upstream diversity." It is "two observed upstream ASNs, physical diversity unverified." That language matters. It respects the public route evidence without pretending BGP can answer fibre-route questions.

The affected users are few in the national data, but concentrated locally

A 214-subscriber operator can still be important. If those subscribers are households in a few buildings, small shops, clinics, tutors, offices or local service providers, an outage can have a visible neighbourhood effect. A small ISP's failure is unlikely to move national internet statistics, but it can remove the only affordable or familiar connection for a customer who chose it because larger providers were unavailable, expensive or difficult to work with in that building.

The company site positions Shivkranti as affordable and local. It says the organisation took the lead in providing affordable broadband access to home users and corporates and continues to offer cheap internet services in the city. The portal terms are framed around recharges, subscriptions, installation charges and online bill payments. The visible customer journey is not a carrier procurement contract; it is a retail or small-business account relationship.

That customer profile changes the failure consequence. A consumer may not know whether the fault sits in a router, partner cable, upstream, ASN route, billing state or local power. They know only that the bill is paid and the connection is down. A small business may depend on UPI payments, messaging, cloud accounting or camera monitoring. A building manager may have to relay complaints even when the fault lies with customer Wi-Fi. Repair communication becomes part of the service.

The customer portal's refund language is limited to particular online-payment failure scenarios; it says a refund may be available when money is charged but recharge is not delivered within 24 hours, after email notice and investigation. That is payment-process evidence, not outage compensation evidence. The portal does not publish an outage-credit policy, service-level agreement, planned-maintenance page or historical incident log. Readers should not infer customer remedies beyond what is visible.

This is where local-support labour returns to the centre. If the network fails, customers need an answer fast enough to make the service trustworthy. Is it a known upstream outage? Is a building switch down? Is there a power cut? Has a cable been cut? Is the customer's account suspended? Is a technician coming today or next week? The public evidence does not show Shivkranti's support process, but a small ISP's reputation often lives in those moments.

National regulation supplies a benchmark vocabulary, not a customer guarantee. The TRAI performance-report page gives the reporting channel through which market-wide performance appears, and the March 2026 PIB summary reports national compliance categories. It does not publish Shivkranti-specific fault restoration. For this company, direct evidence would be a support-status page, a customer notice archive, monthly uptime metrics or audited complaint data.

What would raise the grade

The path from Weak to Medium is straightforward. Shivkranti would need to disclose or corroborate current operating facts that go beyond licence and routing. A serviceability map or address checker would establish where in Mumbai service is actually sold. A technology description would separate fibre, cable, Ethernet and fixed-wireless access. A customer support page with hours, escalation contacts and fault categories would show how the company manages outages. A status page would show current and historical building, upstream or area events.

Network evidence would need to be more specific. Public BGP already shows AS149195, two /24s and two observed upstreams. The missing layer is physical and operational. A stronger record would show whether Vortex and Gigaline are active contractual upstreams, where the handoffs terminate, whether circuits enter over separate paths, whether routers and power are redundant, what capacity each link carries, how failover is tested and whether backup capacity can support the ordinary busy hour. A PeeringDB record, while not mandatory, would help by naming exchange or facility presence if the company has any.

Access evidence would need to show route independence inside the service area. A local ISP can have two upstreams and still fail many customers because one building switch loses power. A credible access disclosure would identify whether customer buildings have active equipment, what backup runtime exists at aggregation points, how many subscribers sit behind each aggregation node, what spares are stocked and how quickly technicians can reach common fault sites. The point is not to expose sensitive route maps; it is to establish that resilience is designed rather than assumed.

Labour evidence would also matter. If the "Select entrepreneurs" arrangement is central, the company could explain partner standards, escalation, inventory and customer demarcation. How are partner faults monitored? Who owns the cable after installation? Who can approve a replacement device? Who speaks to customers when the fault is upstream? Who checks that an entrepreneur's local switch has power protection? A small local network can be resilient with partners, but the controls must be legible.

Finally, customer evidence would help only if bounded carefully. Reviews, social posts and informal complaints can suggest patterns, but they cannot prove network topology or general service quality. A small sample is easily distorted by one building or one angry billing dispute. Useful customer evidence would be time-stamped outage communication, repeated reports from the same area that match a technical cause, or a public incident postmortem. The article found no strong public set of such signals; it therefore leaves customer experience mostly ungraded.

Evidence-bound conclusion

Shivkranti Internet Service Pvt Ltd should remain in the regional-ISP category only with a clear qualifier: Mumbai-local micro-ISP. The public evidence supports a licence, a subscriber portal, a small reported broadband base, an active ASN, an active IPv4 /23 allocation, two visible /24 announcements, valid RPKI for both originated /24s and two observed upstream ASNs. That is enough to say the company is more than a dormant corporate shell or a stray directory name.

It is not enough to say the local bill is resilient. The company does not publicly disclose last-mile medium, access topology, building list, field workforce, partner controls, upstream contract size, facility handoff, physical route diversity, backup power, failover tests, outage history, congestion data or customer repair performance. The February 2026 DoT licence row and APNIC records make the operator real; the June 2025 TRAI subscriber table makes the scale small; BGP makes the edge visible; the missing physical disclosures keep the grade low.

The practical failure path is therefore simple. A Shivkranti customer may be depending on a chain that begins in a Mumbai building, passes through local access plant and a Goregaon West operating surface, reaches AS149195's small IPv4 edge, then exits through Vortex, Gigaline or another configured path. If a building cable is cut, a partner switch loses power, a local technician is unavailable, a circuit fails or an upstream path congests, the customer bill has no inherent protection. Protection has to come from redundancy, documentation, spares and labour.

The final network evidence grade is Weak. The downgrade is not a claim that Shivkranti is non-operational. It is the opposite: public records are sufficient to identify a licensed and routed Mumbai ISP, but insufficient to award a stronger infrastructure-resilience grade. Recommended metadata should keep the category as company-region-global-type-regional-isp, keep the region as IN, keep the topics because regional economics, local repair labour and upstream transit are all implicated, and add an editorial note that the service-area thesis is Mumbai-local and the network-resilience evidence remains weak until the access, upstream and repair controls are independently verified.