MWC Shanghai brings operators, infrastructure providers, device companies, software platforms, cloud and AI businesses, integrators and organisations from connected industries into one venue. A visitor can see many technologies working, yet still leave without knowing who could deliver a real project. MWC Shanghai 2027 becomes more useful when the team brings one deployment case that lets each company explain its role, interfaces, evidence and operating responsibility.
MWC27 Shanghai takes place from 23–25 June 2027 at Shanghai New International Expo Centre. The organiser positions the event around connectivity, AI and technologies moving from development to deployment; its visitor information also highlights areas such as 5G Advanced, cloud, IoT, satellite and non-terrestrial networks, and 6G. The mix supports ecosystem research, but a product demonstration, a pilot and an operating service represent three different levels of evidence.
| Buyer question | Best show activity | Useful output |
|---|---|---|
| Can the technology address our site and user case? | Scenario briefing and architecture discussion | Proposed role, assumptions, interfaces and gaps |
| Does it work with our devices, systems and data? | Targeted demo or technical workshop | Testable integration path and required access |
| Can the partner support a controlled pilot? | Pilot-scope meeting | Success measures, responsibilities, schedule and cost |
| Can the solution operate after rollout? | Service and commercial review | Operating model, SLA, support, lifecycle and exit terms |
Bring a deployment brief, not a shopping list of technologies
Define the user, location, process and intended result before naming products. A useful case might involve connecting equipment across a factory, supporting field workers, managing an IoT device fleet, improving coverage at a site, moving selected processing to the edge, or integrating a connected product with cloud services. State the operational problem and how improvement would be measured.
Describe the current environment: sites and geography, existing network and systems, device population, traffic or data flows, capacity, coverage, latency or availability needs where relevant, power and environmental conditions, security boundaries, user groups and support arrangements. Add project timing, expected scale, internal technical owner, operating owner, purchasing model and known constraints.
Separate mandatory conditions from preferences. A required interface, supported radio band, site condition, hosting boundary or response time can determine feasibility. A preferred dashboard style or optional feature belongs later. This distinction helps partners respond to the same case without turning every meeting into a different product pitch.
The brief should also show the current decision stage. Market discovery needs a map of credible approaches. Architecture selection needs deeper interface and performance evidence. A pilot needs named equipment, sites, users, data, test conditions and owners. A rollout discussion needs service, security, commercial and lifecycle detail. Asking for the next appropriate proof is more productive than asking every exhibitor for a full proposal.
Identify who owns each layer and interface
A connected deployment may include access or spectrum arrangements, radio equipment, core or network functions, gateways, modules and devices, edge compute, cloud services, application software, AI capabilities, security controls, systems integration and ongoing operations. Ask each company to mark the components it supplies directly, partner-delivered components, customer responsibilities and any dependency that remains unresolved.
For network and infrastructure discussions, examine the coverage and capacity model, site assumptions, resilience, backhaul, management, monitoring, upgrades and operational support. Clarify spectrum, carrier, access or licensing dependencies without assuming one answer applies across markets. Where private or hybrid networks are considered, define the boundary between enterprise, operator, equipment and integrator responsibilities.
Device and IoT meetings should cover radio and network compatibility, module or chipset, provisioning, identity, remote management, firmware and security updates, power consumption, environmental rating, certifications or approvals required by the buyer, manufacturing status and expected support life. Ask how devices are recovered, replaced, re-provisioned and retired, not only how they are connected on day one.
Cloud, edge, software and AI discussions need a clear service boundary. Record where processing occurs, which data enters and leaves each layer, required connectivity during degraded conditions, APIs, supported protocols, identity and access model, logging, monitoring and integration with existing workflows. For AI functions, define the input, output, performance measure, known limitations, human review and update process rather than relying on a demonstration label.
An interface register is often more valuable than a long feature list. It should name the two parties at each boundary, data or signal exchanged, format or protocol, timing or performance expectation, authentication, failure behaviour, test owner and unresolved question. This exposes gaps that no single exhibitor presentation is likely to mention.
Turn demonstrations into evidence for the real environment
Before a demo, tell the supplier which part of the deployment case it is expected to prove. Record the hardware and software version, configuration, network conditions, data source, scale and whether the result is live, simulated or pre-recorded. A smooth stand demonstration can establish capability, but the differences between the show environment and the buyer’s site should be listed explicitly.
Ask for a relevant reference case and examine its similarity: industry, geography, user count, device scale, coverage environment, architecture, integrations, operating period and supplier role. References help to frame questions; permission to contact a customer, site or project team depends on the parties involved. Marketing metrics should be connected to the test method and operating conditions before they are used as decision evidence.
Interoperability can be tested in stages. A document review may confirm standards and stated interfaces. A workshop can map architecture and data flows. A lab test can connect representative devices or APIs. A site survey can verify physical and radio assumptions. A proof of concept can then test a controlled part of the real process. Each stage should have a question, input, success measure and decision that follows.
If equipment samples or development kits are taken after the show, identify the model, revision, accessories, firmware, licence, documentation, return terms and permitted use. Assign one technical owner to preserve the configuration and results. Otherwise, a promising test can become difficult to reproduce or compare with the eventual commercial offer.
Design a pilot that can produce a decision
A pilot should test the main uncertainty, not imitate a full rollout at small scale. Define sites, users, devices, traffic or workloads, data, integrations, operating hours, test period and baseline. Select measures that relate to the operational case, such as coverage, connection success, latency, throughput, device availability, power life, task time, error rate, model performance or support response, as applicable.
Assign responsibility for site access, equipment, connectivity, configuration, integration, data preparation, security review, user training, monitoring, incident handling and restoration after the test. Record which results the supplier produces, which the buyer measures and how disagreements will be investigated. The close-out should state whether to stop, revise, extend or prepare a rollout case.
Data, cybersecurity and privacy requirements belong in the pilot scope from the beginning. Map data categories, collection, transfer, storage, access, logs, retention and deletion; identify credentials, remote access, update mechanisms, vulnerability handling, incident notification and subcontracted services. Applicable requirements depend on deployment and jurisdiction, so final review stays with the buyer’s authorised security, privacy, legal and regulatory specialists.
A pilot also needs commercial clarity. Separate hardware purchase or loan, connectivity, platform or software licences, cloud or usage fees, integration, travel, on-site work, data services and support. State what happens to equipment, accounts, data and custom work when the pilot finishes. This allows technical learning without creating an unplanned dependency.
Evaluate the operating partner, not only the launch team
Ask who will design, sell, contract, deploy and support the solution. The exhibitor may be a technology owner, regional office, distributor, integrator or ecosystem partner. Record the legal contracting entity, delivery entities, local and remote teams, escalation path and responsibilities for third-party components.
An operating model should cover monitoring, incidents, service desk, maintenance windows, backups or recovery where relevant, software and firmware updates, component replacement, capacity changes, user administration and reporting. Examine proposed service levels together with measurement method, exclusions, support hours, severity definitions, response and restoration targets, escalation and remedies.
Lifecycle questions matter for both hardware and services. Ask about current release status, planned support period, security updates, compatible replacements, dependency changes, data export, configuration ownership and migration or exit options. For cloud or usage-based services, model recurring charges at expected and higher volumes. For infrastructure, include installation, site work, spares, power, transmission, licences, training and ongoing operation rather than comparing equipment prices alone.
Commercial proposals become comparable when they use the same architecture boundary and workload assumptions. Separate one-time and recurring costs, partner pass-through costs, optional modules, implementation, customisation, support tiers and taxes or delivery assumptions. Note intellectual-property ownership, rights to custom developments, data use, confidentiality and restrictions that the buyer’s legal team must review.
Use Shanghai follow-up for people and systems that cannot move to the stand
The most valuable extension after MWC is often appointment-led rather than a generic factory tour. A local technical centre, integration lab, network operations environment, device engineering team, solution partner or reference deployment may show the people and systems that would support the next proof point. The destination should be selected only after the show meeting identifies a specific unanswered question.
A device or hardware visit can focus on engineering change, manufacturing readiness, test coverage, firmware control, component traceability, provisioning and after-sales repair. A software, cloud or network visit can examine architecture, monitoring, incident workflows, integration practice, release control and the proposed support team. A partner meeting can clarify the contractual and technical hand-offs that were hidden in a combined booth presentation.
End the trip with a decision register for each candidate: proposed role, architecture and interfaces, evidence observed, assumptions, security or data questions, pilot or workshop scope, commercial basis, operating owner, missing information and next gate. This gives the buyer a smaller set of defined follow-ups instead of a larger collection of technology claims.
Xentra can support company research, multilingual meetings, appointment planning, technical-team visits and structured comparison of potential partners. Final architecture, cybersecurity, privacy, network, regulatory, investment, contracting and deployment approval remain with the buyer’s authorised specialists and decision makers.
Sources
- MWC Shanghai official homepage and 2027 dates
- Official MWC27 Shanghai visitor overview
- Official description of the connectivity ecosystem
- Official exhibition and partnership overview
Event information checked on 24 July 2026.