• IoT Edge

▫ Edge intelligence: flow analysis model and algorithm, video analysis model
algorithm, flow analysis engine, and video analysis engine.

▫ Local edge management: rule association, cloud-edge service collaboration,

device data management, device command scrubbing, device access, and
device authentication.

▫ Edge integration: user apps, industry protocols, and third-party gateway

software.

▫ Edge security: secure communication, edge anomaly detection, and trusted

boot.
• An NB-IoT base station is connected by using optical
fibers by using the RRU, antenna system, and
BBU(Baseband Processing Unit). The NB-IoT core
network is managed by the MME. Session management;
User authentication and key management; The HSS, P-
GW, and S-GW provide packet routing and forwarding
functions for signaling encryption and integrity
protection at the NAS layer. However, the S-GW is the
serving gateway, and the P-GW is the gateway
connected to the external or internal packet network of
the carrier.For example, the MME is the public security
department responsible for the management of
floating population, the SGW is the express company
responsible for the transit of people and materials, and
the PGW is the gateway for the entry and exit
inspection of people and materials.
• SKG
• IoT is an Internet where all things are interconnected. This sentence has two
meanings. First, the core and foundation of the IoT is still the Internet. IoT is an
extended network based on the Internet. Second, the IoT connects any thing at
the user end for information exchange and communications.

• The IoT architecture can be divided into four layers:

▫ Sensor

▫ Network

▫ Platform

▫ Application
• DIS collects, processes, and distributes real-time stream data.

• DMS for Kafka is a fully managed, high-performance message queuing service

that enables reliable, flexible, and asynchronous communication between
distributed applications.

• OBS is a cloud storage service.

• ROMA Connect is focused on application and data integration and integrates

messages, data, APIs, and devices.

• IoT Analytics uses IoT data integration, cleaning, storage, analysis, and
visualization to provide one-stop services for IoT data developers.

• MRS provides enterprise-level big data cluster cloud services that can be
completely controlled by tenants.

• CS is a real-time big data stream analysis service.

• IoT data developers can quickly build IoT data lakes and use standard SQL
statements for data analysis and easily process Terabytes or even Exabytes of
data.

• Data lake provides cost-effective massive data storage, seamlessly interconnects

with the IoT Device Access service, quickly accesses IoT data sources, and
preprocesses IoT data based on IoT asset models to prepare for data analysis.

• Big data analytics uses the high-availability big data processing, horizontally
expandable framework, tin-memory computing model, directed acyclic graph
(DAG) scheduling framework, and efficient optimizer to deliver the
comprehensive performance 100 times over that of the traditional MapReduce
model.

• Standard SQL jobs provide standard SQL interfaces and support abundant job
scheduling policy configuration. IoT data developers can stay focused on IoT
services and on developing analysis jobs without worrying about the deployment
and O&M of the SQL processing engine.
• When a device reports data, if Data Type is Binary, a codec needs to be
developed for the product. If Data Type is JSON, codec development is not
required.

• For example, in the NB-IoT scenario where devices communicate with the IoT
platform using CoAP, the payload of the CoAP message is the data at the
application layer and the data type is defined by the device. As NB-IoT devices
have high requirements on power saving, data at the application layer is in
binary format instead of JSON format. However, the IoT platform communicates
with the application by sending data in JSON format. Therefore, codec
development is required for the IoT platform to convert data in binary and JSON
formats.

• Upstream messages: CoAP packets are parsed to obtain the application layer
data. -> Product models and codec are called for encoding. -> Messages are sent
to the application platform.

• Downstream messages: Messages are sent. -> Product models and codec are
used for coding. -> CoAP messages are assembled and sent to devices.
• After defining a product model, you can use it during device registration.
• Identifies a service.

• The directory structure of the product model file must be the same as that shown
in the figure and cannot be added or deleted. For example, the second level can
contain only the product profile and service folders, and each service must
contain the product profile folder.

• The product model is compressed in .zip format.

• The product model must be named in the format of

deviceType_manufacturerId_model. The values of deviceType, manufacturerId,
and model must be the same as those in the devicetype-capability.json file.
• In the data reporting process, the codec is used in the following scenarios:

• Decoding binary data reported by the device into JSON data and sending the
data to the application.

• Encoding the JSON data returned by the NA into binary data and sending the
data to the device.
• In the command delivery process, the codec is used in the following scenarios:

• Encoding JSON data delivered by the NA into binary data and sending the code
to the device.

• Decoding the binary data returned by the device into JSON data and reporting
the data to the application.
• This page describes the components of REST API requests.

• Although a request URI is included in the request header, most programming

languages or frameworks require the request URI to be transmitted separately.

• URI-scheme: protocol used to transmit requests. All APIs use HTTPS.

• Endpoint: domain name or IP address of the server bearing the REST service. It
can be obtained from Regions and Endpoints. For example, the endpoint of IAM
in the CN North-Beijing4 region is iam.cn-north-4.myhuaweicloud.com.

• resource-path: access path of an API for performing a specified operation. Obtain

the path from the URI of an API. For example, the resource-path of the API used
to obtain a user token is /v3/auth/tokens.

• query-string: query parameter, which is optional. Ensure that a question mark (?)
is included before each query parameter that is in the format of "Parameter
name=Parameter value". For example, ? limit=10 indicates that a maximum of 10
data records will be displayed.
• Use the returned X-Subject-Token value in the header field to update X-Auth-
Token in the IoT platform environment so that it can be used for other API calls.
If the token expires, the Authentication API needs to be called again.

• Change the values of IAMEndpoint, IOTDAEndpoint, IAMUserName,

IAMPassword, IAMDoaminId, and region.
• The returned body contains a list of projects. Search for the item whose name is
the same as the value of region in the IoT platform environment, and update the
value of id to the value of project_id in the IoT platform environment so that the
value can be used for other API calls.
• Use the returned product_id value to update the product_id parameter in the IoT
platform environment so that it can be used in other API calls.
• Use the returned device_id value to update the device_id parameter in the IoT
platform environment so that it can be used in other API calls.
• Indicates the subscription callback URL, which is used to receive notification
messages of the corresponding resource event.
https://10.10.10.10:443/callbackurltest is an example value.
• URI: Determined by callbackUrl in the application server request for subscribing
to a device activation event.
▫ 1. ABCD

▫ 2. File that describes device capabilities.

▫ 3. The input parameter binaryData of the decode API is the payload of the
CoAP packet sent by the device. The input parameter of the encode API is in
the JSON format and is a message or response delivered by the IoT
platform.
• Stability and reliability: With reliability built into multiple levels of the
architecture, OBS achieves up to 99.9999999999% (12 nines) data durability, and
maintains an impressive 99.995% service continuity rate.

• Security and trustworthiness: OBS has been awarded the Trusted Cloud Services
(TRUCS) Certification. It secures your data with server-side encryption, URL
validation, black/white lists of IP addresses, VPC-based network isolation, log
audit, and fine-grained permission control.

• Intelligence and efficiency: By leveraging technologies of intelligent scheduling,

accelerated data transfer, and big data analytics, OBS provides users with the
best possible data access experience: 10-million level TPS, 2.4 Gbit/s single-
stream upload, and shorter than 10 ms latency.

• Easy-of-use: OBS has a management console, supports REST APIs, provides multi-
language SDKs, and is compatible with all mainstream client tools. Furthermore,
OBS gives you the freedom to upload, download, and manage your data
anytime, anywhere.
▫ 1. T

▫ 2. ABCD
• This market is commonly called the Low Power Wide
Area (LPWA) market.
• LPWA highlights two typical requirements of
applications in this market: low power consumption
and wide coverage. There is a third requirement for the
applications in this market: low cost. Because this
market requires a large number of connections and a
device needs to be installed on a single plant, animal,
or even instrument, the device cost cannot be too high.
• The Boudica chip is developed by Huawei HiSilicon.
• SoC: System-On-a-Chip
• BB: baseband
• RF: radio frequency
• PMU: power monitoring unit
• AP/SP/CP: three cores defined for the chip: the
application processor, security processor, and
communication protocol
• eFlash: embedded flash
• SRAM: static random access memory
• FOTA: firmware over the air
• Lightweight machine-to-machine (LwM2M) is a client-server-
based DM device management protocol and is mainly
used for restricted devices.
• Uu: the radio interface between the UE and the E-
UTRAN
• Evolved Universal Terrestrial Radio Access Network (E-
UTRAN): a radio access architecture proposed in 3GPP
release 8, featuring high transmission rate, low delay,
and optimized data packets. The E-UTRAN contains
several eNodeBs and provides the E-UTRA user plane
(PHY/MAC) and control plane (RRC) protocols, which
are terminated at the UE.
• UE: user equipment
• Non-Access Stratum (NAS): a functional layer between
the UE and the core network. It supports transmission
of services and signaling messages between the core
network and the UE.
• Evolved packet core (EPC) : an evolved 3GPP core
network framework featuring higher data rates, lower
delay, and optimized packets. It supports multiple radio
access technologies.
• The NB-IoT research and standardization is carried out
by the 3GPP standards organization.
• In May 2014, Huawei proposed NB M2M. In May 2015,
NB OFDMA was converged into NB-CIoT. In July 2015,
NB-LTE and NB-CIoT were further integrated into NB-
IoT. The NB-IoT standard was frozen in June 2016.
• 3GPP (Third Generation Partnership Project): a leading
3G technical specification organization that was
founded in December 1998 by ETSI in Europe, ARIB and
TTC in Japan, TTA in South Korea, and T1 in the United
States. It aims to research, formulate, and promote the
3G standards (WCDMA, TD-SCDMA, EDGE) based on
the evolved GSM core network. China Wireless
Telecommunication Standard Group (CWTS) joined
 3GPP in 1999.
• The products covered by 3GPP include GSM, WCDMA,
TD-CDMA, TD-SCDMA, LTE, and LTE-Advanced. The
current key project is 5G (New RAT).
• At present, 3GPP has three technical specifications
groups covering Radio Access Network (RAN), Service
and System Aspects (SA), and Core Network and
Terminals (CT). NB-IoT standardization is carried out
under the RAN group. (It was carried out under the
GSM EDGE RAN (GERAN) group before August 2015.
Later, this group was incorporated into the RAN group).
• 3GPP specifications download link:
http://www.3gpp.org/specifications/79-specification-
numbering
• The 3GPP working group does not formulate standards.
Rather, it provides technical specifications (TS) and
technical reports (TR), which are approved by the TSG.
Once the TSG approves the TSs and TRs, they are
submitted to the members of the 3GPP working group
for standardization. 3GPP TSs and TRs are represented
by four- or five-digit numbers (xx.yyy). The first two
digits xx are the serial number, and the last two or
three digits yy or yyy indicate a specific specification in
a series.
• Orthogonal Frequency Division Multiple Access
(OFDMA): an evolution of OFDM that combines OFDM
and FDMA. It is a transmission technology that utilizes
OFDM to divide channels into several orthogonal
subcarriers and loads data to be transmitted to some of
these subcarriers.
• OFDMA is a multiple access modulation technology
through which users can access the system by sharing
frequency bands.
• OFDMA is classified into subchannel OFDMA and
frequency hopping OFDMA.
• Single-carrier Frequency-Division Multiple Access (SC-
FDMA): a modulation and demodulation technology
with continuous subcarriers. It is a mainstream multiple
 access scheme in the uplink physical channel of LTE.
• Uplink transmission technologies include single- and
multi-tone transmissions.
• Single-tone:
▫ 3GPP specifications stipulate that NB-IoT should support single- and multi-
tone transmission in the uplink. Single-tone transmission is mandatory for
UEs, while multi-tone transmission is optional.

▫ Single-tone is applied to the uplink physical channel of the NB-IoT,

indicating that the UE occupies only one subcarrier in uplink transmission.
• NB-IoT is based on cellular networks, coexist with
existing networks, and supports smooth evolution of
SingleRAN. NB-IoT consumes only a bandwidth of
approximately 180 kHz and can be directly deployed on
legacy GSM, UMTS, and LTE networks to reduce
deployment costs and achieve smooth upgrade.
• Three deployment modes are supported: standalone,
guard band, and in-band deployment, as shown in the
figures.
▫ Standalone deployment: A separate band can be used. This mode can be
used when GSM frequency bands are re-farmed.

▫ Guard band deployment: Operators can use LTE edge bands not in use to
deploy NB-IoT.

▫ In-band deployment: Operators can use any resource block in LTE carriers
to deploy NB-IoT.
• Ultra-wide coverage: NB-IoT is designed for IoT,
especially LPWA connections. It uses retransmission
over the air interface and ultra-narrow bandwidths to
provide an extra gain of over 20 dB compared with
GSM. This gain reduces the number of sites needed to cover wider
areas with strong signal penetration that can reach
basement levels. Devices such as electricity or water
meters in hard-to-reach areas can be covered. Pet
tracking and other services that require wide coverage
can be used.
• Ultra-low cost: Huawei SingleRAN solution enables
upgrade and reconstruction on legacy network devices
to reduce network construction and maintenance costs.
NB-IoT chips are specifically designed for IoT devices.
The chips apply only to narrowband and low rates and
support only single-antenna transmission and half-
duplex mode in compliance with IoT requirements. In
addition, the signaling processing of NB-IoT chips is
simplified. These reduce the terminal chip price to only
several dollars.
• IoT devices have different communications
requirements from mobile phones. In most cases, an
IoT device sends only uplink data packets, and the
device itself determines whether to send these packets.
It does not need to stand by for calls from other
devices. By contrast, a mobile phone is ready to
respond to network-initiated call requests at any time.
• If IoT communication is designed in a 2G/3G/4G
manner, a large amount of power is consumed when constantly

monitoring possible requests initiated by the network,

which is how a mobile phone functions, failing to
achieve low power consumption.
• Based on NB-IoT technology, an IoT device enters the
dormant state immediately after sending data packets
and wakes up only when data reporting is required
again. An IoT device can be in the dormant state for up
to 99% of total time, achieving super-low power
consumption.
• Gains:
▫ eDRX in idle mode enables the UEs to stay in the PSM for a longer period
and save more power than traditional discontinuous reception (DRX).

• Scenarios:
▫ eDRX applies to scenarios where LTE UEs are used to perform IoT services
and there are energy-saving requirements for the UEs, such as smart
meters, sewer monitoring, and guards for the elderly and children.

▫ This feature applies to cells serving eDRX-capable UEs.

• Max Coupling Loss (MCL): used to evaluate the extent
of coverage (or penetrated range). The larger the
value, the larger the coverage extent (penetrated
range).
• The existing access technologies cannot meet the deep
coverage requirements of IoT. 3GPP TS 45.820 proposes
that LPWA technologies provide an MCL 20 dB higher
than GSM and LTE to support the deployment of IoT
services such as water meter reading and electricity
meter reading.
• Compared with LTE and GPRS base stations, NB-IoT
increases the gain by 20 dB to cover hard-to-reach
areas such as underground garages, basements, and
underground pipelines.
• The frequency spectrum density is improved.
▫ The uplink and downlink physical channel formats and modulation
specifications are redefined to enable uplink and downlink control
information and service information to be transmitted in narrower
bandwidths than with LTE. The PSD gain increases when the transmit power
remains the same, reducing demodulation requirement on the receiver.

▫ Repeated transmission: The encoding scheme used for repeated transmission

is introduced, which promotes the reliability of transmission when the
channel condition is unfavorable.
• NB-IoT base stations are designed based on the IoT
traffic model. The IoT traffic model is different from
the mobile phone traffic model. In the IoT traffic
model, there are a large number of terminals, the
packet sent by each terminal is small, and packet
transmission is insensitive to delay. The 2G/3G/4G base
stations are designed to enable UEs to run services
simultaneously while meeting delay requirements. The
number of connections or admitted UEs is limited to
approximately 1000. In contrast, NB-IoT services are
delay-insensitive, and NB-IoT base stations can be
designed to enable more terminals to be admitted and
more terminal contexts to be saved. An NB-IoT cell can
serve around 100,000 terminals at a time, with a large
number of them in the dormant state. The contexts of
 these terminals are maintained by the base station and
core network. When data needs to be sent, the
terminals can quickly enter the active state.
• In addition, the scheduling granularity is large in
2G/3G/4G and much smaller in NB-IoT because NB-IoT
is narrowband-based. When the same amount of
resources are available, the resource utilization of NB-
IoT is higher than that in 2G/3G/4G. With the same
coverage gain requirements, NB-IoT reduces
retransmission and increases spectrum efficiency.
• 180 kHz
• In-band deployment, standalone deployment, and
guardband deployment
• Ultra-low cost, ultra-low power consumption, ultra-
wide coverage, and massive connections
• PWM: pulse width modulation
• ADC: analog-to-digital converter
• UART: universal asynchronous receiver/transmitter. It
converts the data to be transmitted between serial and
parallel communication.
• The I2C bus is a simple bidirectional two-wire
synchronous serial bus developed by Phillips.
• The AT module is distributed on the APP and
PROTOCOL cores, and the RPC communication mode is
used between cores.
• RPC: remote procedure call. One program can use RPC
to request a service from a program located on another
computer over a network without needing to
understand the underlying network protocols. RPC
 assumes the existence of a transmission protocol such
as Transmission Control Protocol (TCP) or User
Datagram Protocol (UDP) to carry the message data
between communicating programs.
• The APP core initiates tasks, listens to AT commands
received from the UART in the queue, parses characters,
checks parameters, prints execution results, and
transfers messages to the PROTOCOL core through RPC
communication.
• Table 1-1: The JJFA provides the time of each state
based on the typical configuration of the base station.
• The actual discharge capacity of a battery string varies
depending on the discharge current, temperature,
usage, cutoff voltage, and power consumption of the
customer's electrical equipment. You are advised to
contact a battery manufacturer for an accurate
evaluation of the battery capacity and service life.
• Ensure that you understand the customer's focus and constraints
on hardware layout. The customer's focuses may
include the cost, size and layout, and electrical
performance. Design and select antennas based on
customer's focuses.
• The device shells cannot be all sealed with metal
materials. At minimum, the metallic window at the
antenna radiation point must be met.
• Keep the antenna away from RF components, power
supplies, and metal shielding covers.
• For the monopole microstrip antenna of the PCB type,
the ground under the antenna cabling must be clear.
For the monopole antenna with a metallic conductor,
partial folding can be performed to fully use the three-
 dimensional space.
• Planar inverted F antennas (PIFAs) are also commonly
used. A PIFA can be designed in the form of a PCB,
metal spring, or spring+support, depending on the
product space layout and customers' focuses.
• NB-IoT devices can be applied in various scenarios and forms,
and can be implemented in a large number of modes. The antennas
listed in this document are applicable only to limited
application scenarios. Antennas must be designed and
selected based on the product requirement and
application in specific scenarios.
• There are three CPUs: the security protocol processor
(SP), communication protocol processor (CP), and
application protocol processor (AP)
• Environment adaptability test, reliability limit test,
long-term reliability test, and small-scale reliability test
• In this course, we will learn a common IoT protocol,
LwM2M.
• LwM2M is a lightweight IoT application layer protocol
proposed英[prəˈpəʊzd]
• by the Open Mobile Alliance英[əˈlaɪəns].
• What do the letters and digits英[ˈdɪdʒɪts] mean by
LwM2M?
• Who defines the LwM2M protocol?
• Who is the best LwM2M for?
• What is LwM2M?
• LwM2M is short for Lightweight Machine-To-Machine.
• Its name contains two important meanings:
• (1) This protocol is lightweight.
• (2) This protocol is applicable英[əˈplɪkəbl] to IoT
devices.
• The LwM2M protocol is proposed and defined by the
OMA.
• OMA focuses on the development of standards
• in the mobile communications
• and IoT industries and is positioned as a "standard
factory".
• With the rise of the concept of "connected everything",
• The number of IoT terminals has soared英[sɔːd],
• and it is no longer limited to the powerful, large,
smartphones.
• There are a lot of devices with limited power, memory,
• or available bandwidth,
• and the protocols that were used for robust英[rəʊˈbʌst]
 terminal device management
• were too heavy for them,
• so to accommodate英[əˈkɒmədeɪt] these small devices
with limited resources,
• The LwM2M protocol was introduced at
• the end of 2013 to accommodate英[əˈkɒmədeɪt] small
devices with limited power, memory, or bandwidth.
• To sum up, LwM2M is a lightweight IoT protocol for
managing英[ˈmæ nɪdʒɪŋ] terminal devices with limited
resources.
• Next, we will introduce the LwM2M protocol from
several aspects英[ˈæ spɛkts:
• protocol features, architecture, object, and resource
definition.
• First, the LwM2M protocol is a simple object based on
the resource model.
• Resources can be created, retrieved英[rɪˈtriːvd],
updated, deleted, and attribute configuration.
• Resources can also be observed and notified. The
supported data formats include TLV, JSON, Plaint英
[pleɪnt] Text, and Opaque英[əʊˈpeɪk].
• The transport layer used by LwM2M is UDP or SMS,
and the security protocol is DTLS.
• Use the Queue mode to cope with NAT and firewalls.
• Basic M2M functions,
• such as LwM2M server, access control, devices,
• network connection detection,
• firmware update, location and location services, and
statistics英[stəˈtɪstɪks]
• Basic architecture of the LwM2M protocol
• LwM2M uses RESTful CoAP to transmit messages and
data.
• It also uses DTLS over UDP.
• The main entities英[ˈɛntɪtiz] are LwM2M servers and
LwM2M clients.
• The LwM2M server functions as a server and is
deployed
• at the M2M service provider
• or network service provider.
• The LwM2M client is deployed on each LwM2M device.
•
• The LwM2M Server functions as a server
• and is deployed at the M2M service provider
• or network service provider
• to forward data to the device management application
• or device data display application.
• Transmission Control Protocol (TCP) is also a transport layer protocol.

• TCP is connection-oriented. A connection must be established for making a call.

• TCP is more reliable than UDP.

• TCP ensures that messages are delivered error-free, in sequence, and with no
losses or duplications, but TCP is slower than UDP

• TCP connections can only be point-to-point or one-to-one.

• After sending a ClientHello message, the client waits for a HelloVerifyRequest
message from the server. If the client does not receive the ClientHello message, it
determines that the ClientHello or HelloVerifyRequest message has been lost and
resends the ClientHello message. When the server receives the retransmitted
packet, it determines that a retransmission has occurred. The server also
maintains a retransmission timer. After the timer expires, the server retransmits
the message.

• Note that timeout and retransmission do not apply to HelloVerifyRequest

messages. After the server sends a HelloVerifyRequest message, it does not set a
retransmission timer for the message. HelloVerifyRequest is designed to be small
enough to prevent itself from being fragmented. Therefore, you do not need to
consider the scenario where multiple HelloVerifyRequest messages overlap.
• UDP-based, HTTP-like Client/Server Interaction Model

• The client sends a request (carrying a method) to request an operation on a

resource (represented by a URI). The server returns a response (carrying the
representation of the resource) and a status code.

• In the IoT application scenario, the endpoint can be a server or a client.

• The CoAP Messages layer supports message retransmission. It ensures reliable

transmission mechanism without using TCP.

• Note: CoAP runs over UDP. If we consider UDP as a road, messages are cars on
the road, and requests/responses are goods on the cars. Requests/Responses are
placed in CoAP message packages.
• T

• ABCD

• C
• The MQTT protocol was invented in 1999 by Andy Stanford-Clark (IBM) and
Arlen Nipper (Arcom, now Cirrus Link). They needed a protocol for minimal
battery loss and minimal bandwidth to connect to oil pipelines via satellite. The
two inventors set several technical objectives for the future protocol:

▫ Simple implementation and deployment

▫ QoS data delivery

▫ Lightweight, efficient, and low bandwidth

▫ Data agnostic (message encryption)

▫ Continuous session awareness

• About three years after the initial publication, it was announced that MQTT
would be standardized with the help of OASIS, an open organization aiming to
promote standards.

• The standardization process lasted for about one year. On October 29, 2014,
MQTT became an officially approved OASIS standard.
• Unlike the request/response mode, the publish/subscribe mode decouples the
relationship between a publisher and subscriber, making it unnecessary to
establish a direct connection between them. For example, if you call a friend, you
can start communication only after the friend answers the call. This is a typical
synchronous request/response scenario. However, sending an email to a friend
differs. You can do whatever you should do after the email is sent, and your
friend can check the email when they are free. This is a typical asynchronous
publish/subscribe scenario.
• Wildcards can only be used to subscribe to MQTT topics, not to broadcast MQTT
messages.

• Single level: +

▫ The single-level wildcard can only match one level in a topic.

▫ Subscriptions of "huawei/+/humidity" match "huawei/livingroom/humidity"

and "huawei/bathroom/humidity", but do not match
"huawei/home/livingroom/humidity".

• Multi level: #

▫ The multi-level wildcard can match any level in a topic.

▫ It must be placed as the last character of the topic filter and preceded by a
forward slash (/).

▫ After subscribing to the topic "huawei/home/#", you will receive messages

of a topic that begins with the pattern before the wildcard character:
"huawei/home/livingroom" and "huawei/home/bathroom".
• At most one (QoS=0): The publish of messages depends on the underlying TCP/IP
network. Message loss may occur. This level can be used for environment sensors
that can accept read data loss, because environment sensors may send the
second-session data.

• At least once (QoS==1): This level guarantees that all messages arrive at least
once but allows for message duplication.

• Exactly once (QoS==2): This level guarantees that all messages arrive exactly
once. This level can be used in the charging system where message loss or
duplication may cause incorrect results.
• The remaining length is the number of bytes remaining within the current
packet, including data in the variable header (10 bytes) and the payload.

• 10 2C
• To initiate a connection, the client needs to send a CONNECT message to the
broker. If the CONNECT message is incorrect (see the MQTT specification) or too
much time is spent between opening a socket message and sending the
CONNECT message, the broker will close the connection. This behavior can
prevent malicious clients from dragging down the broker.
• Retained messages are used when you want new subscribers of a topic to know
the device status immediately after the subscription. The same is true for clients
that regularly send data such as temperature, GPS coordinates, and other data.
Without retained messages, new subscribers cannot obtain the current status
between publish intervals. However, using retained messages can provide a valid
piece of data for a new client immediately.
• LWT is designed to notify other subscribed clients of the unexpected connection
of a client. In practical use, LWT and retained messages are used together to
store the current state on a specific topic. For example, when the client connects
to the broker, it sends a retained message with the "payload" to the topic
client/status. During the connection, the client sends an LWT message with the
payload "offline" and sets the message as a retained message. If the client is
disconnected unexpectedly, the broker will publish the retained message with the
payload "offline". This mode allows other clients, including newly subscribed
clients, to obtain the client status on a specific topic.
• The keep-alive mechanism ensures that the connection is still available and that
the broker and client are informed of being connected to each other. The client
can set an interval of several seconds and send messages to the broker at the
interval after the connection is set up. The keep-alive mechanism defines the
maximum communication duration that can be accepted by the broker and
client.

• The maximum keep-alive interval is 18 hours, 12 minutes, and 15 seconds. If the

keep-alive interval is 0, the keep alive mechanism is invalid.

• PINGREQ packet is sent by the client to the server in the following cases:

▫ When no other control packet is sent from the client to the server, the
client sends a PINGREQ packet to notify the broker that the client is still
alive. The broker sends a PINGRES packet to tell the client that the broker
keeps alive.

▫ The client sends a PINGREQ packet to confirm the network connection is

still available.
• Currently, browsers cannot use MQTT directly because they do not support basic
TCP connection.
• Answers:

▫ TCP, Publish/Subscribe

▫ B

▫ ABC

▫ False
• The formula for converting rssi to dBm in CSQ is as follows:

• dBm = rssi x 2 - 113

• For example, when rssi is 30, the corresponding dBm is –53 dBm.
• Set commands, test commands, query commands, and execution commands with
and without parameters.

• It is used to query the EPS connection status.

• Huawei LiteOS is a soft real-time OS.
• Dynamic loading: When the program needs to execute code in the dependent
module, the external module is dynamically loaded and linked to the memory.
When the module is not required, the external module can be uninstalled. In this
process, functions such as code sharing and smooth upgrade are implemented.

• Distributed loading: applicable to the quick startup of key services. Services are
loaded in phases, and key services are first.

• Static tailoring: For unnecessary functions and modules, after static tailoring, the
size of the bin and software package of a specific board decreases to reduce
memory overheads. When using static tailoring, remove the symbol dependency
by using the compilation configuration (such as a configuration item), ensuring
the compilation unit of the function or module is not linked.
• The NB-IoT+MCU mode is a common combination. In this mode, the MCU is
used as the main control unit to collect and control data. It sends AT commands
to the module, thereby implementing data interaction between the device and
Internet. The OpenCPU uses the processing capability of the module to complete
the MCU's work. Therefore, the MCU is not required.
• The MIPI RFFE interface is used to connect to an external RF circuit interface.

• One universal UART interface (1.5 Mbit/s in total), two low-power UART
interfaces (supporting asynchronous operations in low-power mode), two I2C
interfaces (1 Mbit/s in total), two SPI interfaces (24 Mbit/s in total), one 10-bit
ADC (818 ksps), one 10-bit DAC, one high-speed analog comparator, and 22
programmable I/Os (configurable)

• Among the 40 PIO pins of the Hi2115, 24 are available on the application core.
The I/O pin functions of each PIO are controlled by software, including the
direction, interrupt configuration, drive strength, and integrated pull-up and pull-
down resistors.
• High real-time performance and stability. Ultra-small kernel. The basic kernel can
be tailored to less than 6 KB. Low power consumption. Dynamic loading and
distributed loading. Static tailoring.

• Scheduling mechanism: centralized task scheduling; transfer mechanism:

lightweight network protocol stack, improved routing algorithm, and Sleeping
Router
• The kernel promotes lightweight competitiveness with
support for a wide range of chips and hardware,
including Cortex-M + Cortex-A, ARM + Intel, Huawei +
3rd , and more.
• https://github.com/LiteOS/LiteOS_Lab/blob/iot_link/doc
/Huawei_IoT_Link_SDK_Developer_Guide.md
• Ready to Running: After a task is created, it enters the
ready state. When a task is switched, the task with the
highest priority in the ready list is executed and enters
the running state. However, the task remains in the
ready list.
• Running to Blocked: When a running task is blocked
(suspended, delayed, or waiting to read semaphores),
the task is deleted from the ready list and the status
changes from running to blocked. Task switching then
occurs, and the task with the highest priority in the
ready list is executed.
• Blocked to Ready (Blocked to Running): After a blocked
task is restored (the task is restored, the delay times
out, the semaphore reading times out, or the
semaphore is read), the task is added to the ready list
and changes from the blocked state to the ready state.
In this case, if the priority of the restored task is higher
than that of the running task, a task switchover occurs,
 and the restored task changes from the ready state to
the running state.
• Ready to Blocked: A task may be blocked (suspended) in
the ready state. In this case, the task status changes
from ready to blocked, the task is deleted from the
ready list, and it does not participate in task scheduling
until it is restored.
• Running to Ready: Task scheduling is performed after a
task with a higher priority is created or restored. At this
time, the task with the highest priority in the ready list
changes to the running state. The original running task
then changes from the running state to the ready state,
and remains in the ready list.
• Running to Dead: When a running task completes, the
task status changes from running to dead. The dead
status includes the normal exit after the task is
complete and the impossible state. For example, if the
separation attribute (LOS_TASK_STATUS_DETACHED) is
not set for a task, the task is in the invisible state (dead)
after the task is complete.
• Blocked to Dead: A blocked task calls the deletion API,
and the task status changes from blocked to dead.
• #include <osal.h>
• #define USER_TASK1_PRI 12
• #define USER_TASK2_PRI 11
• uint32_t user_task1_id = 0;
• uint32_t user_task2_id = 0;
• Post operation: releases semaphores.
• There are three semaphore application modes: non-
block, permanent block, and scheduled block.
• Non-block mode: The task needs to apply for a
semaphore. If the task number of the current
semaphore does not reach the upper limit, the
application is successful. Otherwise, the application
failure is returned.
• Permanent block mode: A task needs to apply for a
semaphore. If the task number of the current
semaphore does not reach the upper limit, the
application is successful. Otherwise, the task enters the
blocked state and the system executes the task with
the highest priority in the ready task. After a task
enters the blocked state, it can only be executed again
 after another task releases the semaphore.
• Scheduled block mode: A task needs to apply for a
semaphore. If the task number of the current
semaphore does not reach the upper limit, the
application is successful. Otherwise, the task enters the
blocked state and the system executes the task with the
highest priority in the ready task. After a task enters the
blocked state, it can be executed again when the
specified time expires, or when another task releases
the semaphore.
• Note: The interrupt cannot be blocked. Therefore, the
block mode cannot be used in the interrupt when the
semaphore is applied for.
• Semaphore operation diagram: There are four tasks in
the public resources. After the semaphore is obtained
by threads 1, 2, 3, and 4, the resources are locked and
not available for thread 5. Thread 5 and subsequent
threads enter the block. When thread 1 completes its
work and releases the semaphore, thread 5
immediately obtains the semaphore and is executed.
This process then repeats.
• A semaphore is a flexible synchronization mode, and
can be used in multiple scenarios to implement
functions such as lock, synchronization, and resource
counting. It can also be used in synchronization
between tasks and between an interrupt and a task.
• *semp: indicates the address of the semaphore index ID.
limit: indicates the maximum value of the semaphore
count. initvalue: indicates the initial value of the
semaphore count. Return value: false indicates that the
creation fails, and true indicates that the creation is
successful.
• semp: indicates semaphore index ID; timeout: indicates
the timeout interval (32 bits).
• #include <osal.h>
• #define USER_TASK1_PRI 12
• #define USER_TASK2_PRI 11
• osal_semp_t sync_semp;
• In a multi-task environment, multiple tasks may access
the same public resources. However, some public
resources are not shared, requiring tasks to be
processed exclusively. In such cases, the mutex avoids
conflict as follows:
• 1. Two tasks cannot lock the same mutex. If a task
locks a mutex held by another task, it is suspended
until the mutex is unlocked.
• 2. The mutex cannot be used in the interrupt service
program.
• 3. As a real-time OS, Huawei LiteOS must ensure real-
time task scheduling and avoid extended task blocking.
Consequently, the mutex needs to be released as soon
as possible after being obtained.
• 4. The priority of a task that holds the mutex cannot be
changed by calling priority adjustment functions.
• *mutex: indicates the address of the mutex index ID.
• Mutex: indicates the mutex index ID.
• Return value: false indicates that the creation fails, and
true indicates that the creation is successful.
• Initialize memory: You must initialize the memory pool
before using the memory. LiteOS initializes the
managed memory during kernel initialization.
__LOS_HEAP_ADDR_START__ specifies the start address
of the memory, __LOS_HEAP_ADDR_END__ specifies
the end address of the memory, and
OS_SYS_MEM_SIZE specifies the size of the memory
pool. You can modify the size of the memory pool in
the scatter file, but it cannot exceed the RAM region of
the chip.
• Apply for memory: After the system is initialized, you
can apply for memory from that managed by LiteOS. In
LiteOS, LOS_MemAlloc() is used to apply for memory
from the specified memory pool based on the required
memory size, which cannot exceed the available
memory managed by the system. The LOS_MemAlloc()
 function can be called three times to apply for three
memory spaces. If we assume that the names of the
memory spaces are UsedA, UsedB, and UsedC, the sizes
of the memory spaces are sizeA, sizeB, and sizeC
respectively, and the remaining memory space is
marked as FreeNode. There is only one large FreeNode
when the memory pool is initialized, so these memory
blocks are divided from that FreeNode.
• Release memory: Memory is a limited resource in the
embedded system, and should be rapidly released when
the application no longer requires it. In LiteOS,
LOS_MemFree() is used to release memory that is no
longer used. Through this process, LiteOS automatically
releases the unnecessary memory to the memory pool
managed by the system. For example, if
LOS_MemFree() is called to release the memory block
UsedB, the memory block UsedB is reclaimed and
marked as FreeNode.
• Operational Mechanism
• Dynamic memory management: When memory
resources are sufficient, memory blocks of any size are
allocated from a large contiguous memory (memory
pool) configured in the system based on user
requirements. When the user does not need the
memory block, it can be released back to the system to
be used again. Compared with static memory, the
advantage of dynamic memory management is that
memory is allocated on demand. The disadvantage is
that fragments are often generated in the memory
pool.
• The LiteOS dynamic memory supports two standard
algorithms: DLINK and BEST LITTLE.
• Part 1 is the start address of the heap memory (also
called the memory pool) and total size of the heap
region.
• Part 2 is an array, and each element is a bidirectional
linked list. The control headers of all free nodes are
classified and mounted to the bidirectional linked list of
the array. Whenever memory is applied for, the system
searches for the most appropriate free node from this
array and then allocates memory. Whenever memory is
released, it is stored in this array as a free node for
future use.
• Part 3 is a large portion of the memory pool, and the
actual region used to store each node.
• For example, if a user applies for 20 bytes of memory,
they are applying for a slab with a size of 32 bytes in
the slab class. If the application is successful, the
system returns the entire memory slab to the user and
reclaims it when releasing the memory. If no slab is
available that meets the requirements, the system
continues to apply for memory blocks from the
memory pool based on the optimal adaptation
algorithm. Note: if no slab is available in the slab class,
an application is made directly to the memory pool,
and no application is made to the slab class with a
larger slab space.
• Dynamic memory development process: describes the
BEST LITTLE development process.
• Static memory pool region, which can be obtained by
defining a global array or calling the dynamic memory
allocation API. If the dynamic memory allocation mode
is used, and the static memory pool is not required,
release the memory segment to avoid memory leakage.
• size: indicates the size of the memory that is applied
for in bytes. Return value: If the memory is successfully
allocated, a memory block pointer is returned. If the
memory fails to be allocated, NULL is returned.
• addr: indicates the pointer for dynamically allocating
memory space. Return value: none.
• ptr: pointer that has been allocated memory space.
• n: indicates the number of allocated memory blocks.
• The interrupt mechanism enables the CPU to execute
other tasks when it is not required by the peripherals.
When the CPU is required by the peripherals, it can
interrupt the current task by generating the interrupt
signal. As such, the CPU does not need to spend a lot
of time waiting and querying the peripheral status,
which greatly improves the real-time performance and
execution efficiency of the system.
• Interrupt Hardware Classification
• Interrupt-related hardware can be classified into three
types: device, interrupt controller, and CPU.
• Device: the source that initiates an interrupt. When the
device needs to request the CPU, an interrupt signal is
generated and connected to the interrupt controller.
• Interrupt controller: one of the CPU's peripherals. The
interrupt controller receives the input of the interrupt
 pins from other peripherals, and then sends interrupt
signals to the CPU. The interrupt controller can be
programmed to set the priority, trigger mode, and
startup/stop status of the interrupt source.
• Common interrupt controllers are as follows:
• Vector interrupt controller (VIC)
• General interrupt controller (GIC)
• Nested Vector Interrupt Controller (NVIC) used in the
ARM Cortex-M series.
• CPU: responds to the request of the interrupt source,
interrupts the ongoing task, and executes the interrupt
processing program.
• (1) and (3): If an interrupt occurs when the task is
running, the task is interrupted. In this case, the
operating system saves the context of the current task
and processes the interrupt service function.
• (2) and (4): The context of the task is resumed and the
task execution continues only when the interrupt
service function is processed completely.
• (1) Interrupt 2 occurs when the service function of
interrupt 1 is processed. The priority of interrupt 2 is
higher than that of interrupt 1, resulting in interrupt
nesting. In this case, the operating system first saves
the context environment of the current interrupt
service function, and then turns to process interrupt 2.
(2) Interrupt 1 continues only when interrupt 2 is
complete.
• Notes:
• Configure the maximum number of supported
interrupts and the address of the interrupt initialization
register based on the specific hardware.
• If the interrupt handler takes too long, the CPU will be
unable to effectively respond to interrupts.
• The scheduling function cannot be executed after the
interrupt is disabled.
• Interrupts 1–15 in the Cortex-M series processors are
for internal use. As such, you are not advised to apply
for and create them.
• The following functions are implemented:
• 1. Initialization of hardware interrupts: You can add
hardware interrupts based on hardware conditions.
• 2. Interrupt registration: You can select and register the
interrupt number, priority, interrupt entry function, and
formal parameters of the interrupt entry function.
• 3. Interrupt triggering: The interrupt function is
executed only when triggered externally or internally.
• 4. Viewing the output result: The print function is
implemented in the interrupt function.
• Queue Operation Principle
• When a queue is created, the corresponding memory
space is allocated based on the queue length and the
number of message nodes transferred by the user. A
queue ID is then returned.
• The queue control block defines the head and tail of
the message nodes to indicate the message storage
status in the queue. The head is the start of the
occupied message nodes in the queue, and the tail is
the start of idle message nodes. When a queue is
created, both Head and Tail point to the start of the
queue.
• When data is written to a queue, it is written to the
idle message nodes found based on the position of Tail.
 If Tail points to the tail of the queue, rewinding starts.
usWritableCnt determines whether data can be written
to the queue. If the queue is full (that is, usWritableCnt
is 0), data cannot be written.
• When data is read from a queue, the first occupied
message node is found based on the position of Head. If
Head points to the tail of the queue, rewinding starts.
usReadableCnt determines whether the queue has
messages to read. If the queue is empty (that is,
usReadableCnt is 0), tasks are suspended.
• When a queue is deleted, it is found based on the input
queue ID. Ensure that the queue status is set to unused,
the space occupied by the queue is released, and the
Head of the queue is set to the initial state.
• Self-networking of a large number of street lamps
(rapid self-healing, reliable, and networking time for
1000+ nodes less than 20 minutes)
• Multiple sensing algorithms available for applications
• Abstract sensor APIs, shielding hardware details and
achieving PnP
• The LiteOS SDK device-cloud interconnection
component provides different software architectures for
two application scenarios: "single-module, single-
MCU", and "external MCU + module".
• High real-time performance and stability. Ultra-small
kernel. The basic kernel can be tailored to less than 6
KB. Low power consumption. Dynamic loading and
distributed loading. Static tailoring.
• The interconnection framework ensures interconnection
and interworking between terminals running different
protocols, the sensor framework provides unified
management of sensors, and the security framework
ensures LiteOS security performance.
• The four states are: ready, running, blocked, and dead.