GB2598889A

GB2598889A - Internet of things distributed network with non-IP data delivery

Info

Publication number: GB2598889A
Application number: GB2014030.7A
Authority: GB
Inventors: Abekov Shaimerden; Abekov Kubat
Original assignee: Hexonet Ltd
Current assignee: Hexonet Ltd
Priority date: 2020-09-07
Filing date: 2020-09-07
Publication date: 2022-03-23
Also published as: GB202014030D0; WO2022049380A1

Abstract

An internet of things IoT distributed network enabling end to end non-IP data delivery of a message addressed to a destination using a persistent subscriber identifier comprising at least one digit encoded as a hexadecimal character. The identifier may be a cellular subscriber identifier part of an international mobile subscriber identity (IMSI) or a mobile station international subscriber directory number (MSISDN). The source of the message may have an associated persistent subscriber identifier comprising at least one digit encoded as a hexadecimal character. The identifier may be in a pre-loaded profile of an embedded or integrated subscriber identity module (SIM) of the source. The message may be a machine to machine (M2M) message and may be routed via a visited network in a roaming context. The network may comprise a core and radio access network. The visited network may determine a home network using the subscriber identifier. The message may be routed to the destination via a home network. The home network may comprise a core network without a radio access network. The home network may comprise a cloud core network. The home network may provision persistent subscriber identifiers having at least one hexadecimal digit.

Description

TITLE

Internet of Things distributed network with non-IP data delivery

TECHNOLOGICAL FIELD

Embodiments of the present disclosure relate to an Internet of Things distributed network with non-IP data delivery.

BACKGROUND

An Internet of Things (loT) is a network of distributed computing devices provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.

An loT enables machine-to-machine (M2M) communication. M2M communication does not necessarily need direct human interaction. M2M services could automate decision making and communication processes.

Setting up a large loT distributed network requires the deployment of large numbers of loT devices and provision of a continuous network coverage for those devices.

BRIEF SUMMARY

The invention is as defined in the appended independent claims.

According to various, but not necessarily all, embodiments there is provided an Internet of Things distributed network configured to enable end-to-end non-IP data delivery (NIDD) of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character ('hex character). In some examples the message source may also have a persistent subscriber identifier with at least one hex character.

NIDD enables the loT devices lobe configured without IP (Internet Protocol), for power saving and reduced processing demands. Communication could be via a telephony network using a low power radio transceiver.

End-to-end NIDD means that both the sender and the destination of the message are non-IP data capable devices. This advantageously requires no intermediate conversion to IP protocol and therefore no extra provisioning of IP addresses. A service provider/manufacturer can launch their own specific software applications. An example software application can be used for security purposes, as the manufacturer can (no matter where the end user is) validate the end user's device and act on the device on the end user's behalf. For example, an loT device locks the end user's smart car and there is no way for the end user to unlock it, as it has good security, but with this technology the manufacturer can unlock it for the end user, as they can uniquely identify the end user's car and they have direct access without IP.

The network as a whole is separated from IP and the Internet, hence having increased security. A hacker cannot access the network through the Internet. The closed network can only be accessed through authorised users The use of a hexadecimal character in the persistent subscriber identifier enables easier registration to a telephony network. The extra character enables data to be routed directly to a home cloud server network. The extra character significantly increases the address space available without adding extra bits. For example, a four-bit binary can support sixteen different values 0-9 and A-F. This enables large loT distributed networks to utilize telephony network resources without limiting network size and without modifying existing network software and hardware to accommodate more bits. Using the letters A-F in the first digit of a 12-digit numeration (and allowing the other 11 digits to have 16 hexadecimal values), the numbering capacity is in the order of 6 x 1611 = 105 553 116 266 496 numbers.

In some examples the persistent subscriber identifier is a cellular subscriber identifier. In some examples the persistent subscriber identifier is at least part of a mobile station international subscriber directory number (MSISDN) and/or a mobile station international subscriber directory number (IMSI). The hex character could be the first digit, for example. Persistence refers to permanence over at least a plurality of message exchanges, handovers, location updates, etc, unlike a temporary mobile subscriber identity (TMSI).

An advantage is improved mobility of loT devices. This is because the loT distributed network can utilize cellular roaming protocols and agreements to route traffic without requiring the loT device to be individually registered to visited cellular networks. The hex character could take the place of the country code and/or national destination code of an MSISDN, for example.

In some examples the persistent subscriber identifier of the loT device is comprised in a profile of a subscriber identity module (SIM) of the source. In some examples the SIM is an embedded SIM (eSIM) or integrated SIM (iSIM). In some examples the profile is a preloaded profile.

An advantage of eSIM and iSIM is reducing the size and complexity of the loT device, because a SIM slot is no longer needed.

In some examples the message is an M2M message. In an example implementation, an M2M message from an loT device (client) to a service provider/manufacturer (server) may report sensor-dependent data. An M2M message from a server may comprise a command to control the loT device.

In some examples, the network comprises a home network for routing the message, that comprises a core network without a radio access network (RAN). The home network may be a virtualized (e.g. cloud) network, for example. The home cloud network may be a public cloud or an enterprise cloud.

An advantage is that the home network can be rapidly deployed without requiring allocation of radio resources or construction of a RAN of base stations. Communication could require roaming of other mobile network operator (MNO) networks. Alternatively, an M NO with its own RAN could implement the invention.

In some examples the home network is configured to provision persistent subscriber identifiers each having at least one hexadecimal digit. An advantage is that loT devices can be manufactured or deployed with an already-provisioned subscriber identifier linking the device to the network, requiring no further registration. The loT devices may not require user intervention for registering the persistent subscriber identifier.

According to various, but not necessarily all, embodiments there is provided a method of communicating in an Internet of Things distributed network, the method comprising: enabling end-to-end non-IP data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.

According to various, but not necessarily all, embodiments there is provided computer software that, when executed, causes the method to be performed. According to various, but not necessarily all, embodiments there is provided a non-transitory computer-readable storage medium comprising computer software (instructions) that, when executed by a processor, causes the method to be performed.

According to various, but not necessarily all, embodiments there is provided an Internet of Things distributed network apparatus comprising means for enabling end-to-end non-IP data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character. In one example the apparatus is a mobile equipment configured as an loT device. In another example the apparatus is a core network entity such as a switch (mobile switching centre MSC).

According to various, but not necessarily all, embodiments there is provided a machine-to-machine communication distributed network configured to enable end-toend non-IP data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.

BRIEF DESCRIPTION

Some examples will now be described with reference to the accompanying drawings in which: Figure 1 illustrates an example of an loT distributed network; Figure 2 illustrates an example of an apparatus; and Figure 3 illustrates an example of a non-transitory computer-readable storage medium.

DETAILED DESCRIPTION

Figure 1 shows the topology and element interaction protocols of an loT distributed network with end-to-end routing of non-IP traffic. The figure's elements are labelled as following: 1 -loT distributed network 100-home cloud network 101 -switch (MSC) 102 -gateway (G-MSC) 103-Home Location Register (HLR) 104 -Visitor Location Register (VLR) 105-USSD request server 106-Short Message Service Center (SMSC) -visitor roaming network 201 -switch (MSC) 202 -gateway (G-MSC) 203-Home Location Register (HLR) 204 -Visitor Location Register (VLR) 205-USSD request server 206 -Short Message Service Center (SMSC) 207 -base station subsystem 300 -manufacturer server 301 -service provider server 302 -mobile equipment (e.g. loT device) (ME) The loT distributed network 1 comprises a home cloud network 100 and a ME 302. For illustrative purposes, one ME 302 is shown whereas in an implementation the network 1 would comprise a plurality of MEs 302, for example tens, hundreds or thousands of MEs 302.

The ME 302 is able to communicate with servers via the home cloud network 100 and via a visitor roaming network 200.

The ME 302 connects to the visitor roaming network 200 and is authenticated based on its IMSI and MSISDN.

The visitor roaming network 200 is an MNO-owned mobile communication network with a core network comprising: switch (MSC) 201, gateway (G-MSC) 202, Home Location Register (HLR) 203, Visitor Location Register (VLR) 204, Short Message Service Center (SMSC) 206, and Unstructured Supplementary Service Data (USSD) request server 205. The visitor roaming network 200 may further comprise a RAN comprising a base station subsystem 207.

The home cloud network 100 comprises a core network comprising a switch (MSC) 101, gateway (G-MSC) 102, Home Location Register (HLR) 103, Visitor Location Register (VLR) 104, Short Message Service Center (SMSC) 106, Unstructured Supplementary Service Data (USSD) request server 105. Some of the elements could be omitted depending on the implementation, or other elements (that don't have implementations in existing traditional mobile networks) can be added.

In some, but not necessarily all examples the home cloud network 100 does not have its own RAN of base station subsystems. The interaction of the home cloud switch 101 with the MEs 302 is carried out through visitor roaming networks 200. The home cloud network 100 may interact with visitor roaming networks 200 via the Signalling System No. 7 (SS7) protocol.

The absence of its own network of base stations relieves the operator of the home cloud network 100 from the burden of obtaining the necessary licenses and radio frequency resources. Also, with such a network topology, operational production costs are reduced, whilst the services can be provided globally.

The servers of loT device manufacturers/vendors 300 and/or service providers 301 have connections to the ME 302 via the home network switch 101, using IMSI/MSISDN as persistent subscriber identifiers.

If the home cloud network is a multi-enterprise cloud or a public cloud, the servers of various manufacturers 300 and/or service providers 301 are connected to the home cloud network 100 as subscribers. Each server 300/301 may define its own independent loT distributed network of MEs 302.

In at least some examples of the invention, a persistent subscriber identifier of a client 300, 301, 302 comprises at least one of the hex characters A, B, C, D, E or F. In one embodiment the persistent subscriber identifier is an MSISDN. The IMSI may remain the same (numbers only). In a second embodiment, a hex character is applied to the IMSI, for example in the place of the mobile country code (MCC) of the IMSI.

The hex character 0-9 A-F takes the place of a number between 0-9. The hex character may be encoded using the same number of bits (at least 4 bits) that was previously used to encode a number between 0-9. These 4 bits contain the possibility for 16 different values. In hexadecimal numeration, the remaining six combinations correspond to the letters of the Latin alphabet: A (1010), B (1011), C (1100), D (1101), E (1110), F(1111).

By using the same number of bits, a hexadecimal character can be used without substantial hardware or software changes to existing telephony networks. This is despite ITU recommendations currently regulating the distribution of only the numbers 0-9. Expansion to include additional letters other than A-F may require handling of an extra bit, so additional changes would be required.

In some examples the at least one hex character is a digit (e.g. first digit) that is recognised as a country code and/or is a digit recognised as a national destination code. The home cloud network is therefore seen by visited networks as a distinct home country/mobile network operator even though it is not necessarily either of these things. Therefore, a roaming (internetwork) agreement with visited networks enables loT device mobility without the need for manual registration of each loT device to different networks.

To route calls to/from devices with hexadecimal numbering, it is sufficient for the operators of the visitor roaming network 200 to register the routing of this code according to the terms of an internetwork agreement. At the same time, no changes are required in the internal algorithms of the MNO.

In at least some examples of this disclosure the hexadecimal characters are applied to the identifiers of M2M-communication devices such as loT devices, rather than to the subscriber identifiers of personal communication devices for making calls (e.g. mobile phones). This is because the addition of a hex character to identify a personal communication device may create problems because standard dialers do not include the letters A, B, C, D, E, F. loT devices using an M2M interface do not require a human-operated dialer so the loT device 302 can be configured to automatically insert hexadecimal characters.

Each manufacturer 300 or service provider 301 may have its own address space (numbering capacities) for provisioning persistent subscriber identifiers to M Es 302.

Using the letters A-F in the first digit, one can obtain a numbering capacity (address space) in an amount ranging from 6 x 161'11 = 1.06 x 10^14 (rounded number) (with 12-digit numbering) to 6 x 16^14 = 4.32 x 10^17 (rounded number) (with 15-digit numbering) items. This indicates the potential number of devices that can be connected without running out of address space.

When the ME 302 is turned on for the first time or later, the subscriber can download the profile of the visitor roaming network 200 or any desired MNO onto the e-SIM (or SIM, iSIM, nuSIM), and organise the interaction directly, since e-SIM supports downloading and managing multiple profiles. This can be done by the manufacturer or service provider prior to deployment, or automatically after deployment. The download of the profile of another MNO can be initiated by the manufacturer 300 or the service provider 301 in the deployed network of Figure 1.

The possibilities of the invention are not limited to SIM, eSIM, iSIM, or nuSIM technologies, it can also be used for other promising developments.

These servers are also assigned IMSI and MSISDN numbers. The hex character for a given server 300/301 could be the same or different as the hex character assigned to the ME 302.

Manufacturers 300 and service providers 301 can have both single and multiple connections with the home cloud switch 101 of the home cloud network 100, and the multiplicity can be organised as a multi-channel connection routed over one MSISDN/IMSI, or to a set of MSISDNs/IMSIs assigned to the manufacturer 300 or service provider 301 in accordance with their requests.

These connections are organised over secure channels and can deliver at least end-to-end non-IP data delivery (NIDD). Thus, manufacturers 300 and service providers 301 can interact with MEs 302 without IP. Therefore, the home cloud network 100 does not need to convert between non-IP and IP.

If the non-IP message is ME-initiated and is addressed to the MSISDNAMSI of the manufacturer 300 or the service provider 301 as a destination, then the request is routed to the destination using existing communication network protocols. Reverse requests where the ME 302 is a destination are handled similarly.

At least some embodiments expand the possibilities for manufacturers 300 or service providers 301 as they obtain their own hex characters in the international numbering plan. Currently, subscribers can only have the number of one or another telecom operator, but with the introduction of the invention, their hex character can show belonging to a particular manufacturer 300 or service provider 301. A hex character could also identify the particular home cloud network 100 in a switch 201 of the visitor roaming network 200, so that the visited network 200 can forward the message via the home cloud network 100.

In some, but not necessarily all examples, if regular IP traffic is sent/received to/from an IP-capable ME 302 or to/from the servers of the manufacturer 300 or the service provider 301, then it is routed in the usual way.

Embodiments of the invention provide the possibility of quickly deploying an loT distributed network over a wide area in an emergency situation (for example, forest fires, earthquakes or epidemics). All MEs 302 are ready for work, and the server of the manufacturer 300 or service provider 301 can be located locally, for example, in a car or van.

In some, but not necessarily all examples communication may take place over service communication channels, for more reliable M2M communication. The non-IP messages could be formatted as USSD requests, AT commands, manufacturer/service-specific message protocols, for example.

For example, if there are overloads in the communication channels (data channels or voice channels), or for other reasons, then the delivery channel for critical requests can be organised via service communication channels. If a USSD message format is used, a USSD request from the ME 302 is addressed to the USSD server of the equipment manufacturer 300 or of the service provider 301. The USSD server 205 of the visitor roaming network 200 will direct such a request towards the destination. Similarly, a USSD request can be sent from the manufacturer 300 or the service provider 301 to the ME 302.

Figure 2 illustrates an example of a controller 300. Implementation of a controller 300 may be as controller circuitry. The controller 300 may be implemented in hardware alone, have certain aspects in software including firmware alone or can be a combination of hardware and software (including firmware).

As illustrated in Figure 2 the controller 300 may be implemented using instructions that enable hardware functionality, for example, by using executable instructions of a computer program 308 in a general-purpose or special-purpose processor 304 that may be stored on a computer readable storage medium (disk, memory etc) to be executed by such a processor 304.

The processor 304 is configured to read from and write to the memory 306. The processor 304 may also comprise an output interface via which data and/or commands are output by the processor 304 and an input interface via which data and/or commands are input to the processor 304.

The memory 306 stores a computer program 308 comprising computer program instructions (computer program code) that controls the operation of the apparatus (e.g. 300, 301, 302, 100-106, 200-207) when loaded into the processor 304. The computer program instructions, of the computer program 308, provide the logic and routines that enables the apparatus to perform the methods described herein. The processor 304 by reading the memory 306 is able to load and execute the computer program 308.

The apparatus therefore comprises: at least one processor 304; and at least one memory 306 including computer program code the at least one memory 306 and the computer program code configured to, with the at least one processor 304, cause the apparatus at least to perform: enabling end-to-end non-IP data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.

As illustrated in Figure 3, the computer program 308 may arrive at the apparatus via any suitable delivery mechanism 400. The delivery mechanism 400 may be, for example, a machine readable medium, a computer-readable medium, a non-transitory computer-readable storage medium, a computer program product, a memory device, a record medium such as a Compact Disc Read-Only Memory (CD-ROM) or a Digital Versatile Disc (DVD) or a solid state memory, an article of manufacture that comprises or tangibly embodies the computer program 308. The delivery mechanism may be a signal configured to reliably transfer the computer program 308. The apparatus may propagate or transmit the computer program 308 as a computer data signal.

Computer program instructions are for causing an apparatus to perform at least the following or for performing at least the following: enabling end-to-end non-IP data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.

The computer program instructions may be comprised in a computer program, a non-transitory computer readable medium, a computer program product, a machine readable medium. In some but not necessarily all examples, the computer program instructions may be distributed over more than one computer program.

Although the memory 306 is illustrated as a single component/circuitry it may be implemented as one or more separate components/circuitry some or all of which may be integrated/removable and/or may provide permanent/semi-permanent/ dynamic/cached storage.

Although the processor 304 is illustrated as a single component/circuitry it may be implemented as one or more separate components/circuitry some or all of which may be integrated/removable. The processor 304 may be a single core or multi-core processor.

References to 'computer-readable storage medium', 'computer program product', tangibly embodied computer program' etc. or a 'controller', 'computer', 'processor' etc. should be understood to encompass not only computers having different architectures such as single /mulfi-processor architectures and sequential (Von Neumann)/parallel architectures but also specialized circuits such as field-programmable gate arrays (FPGA), application specific circuits (ASIC), signal processing devices and other processing circuitry. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc. Where a structural feature has been described, it may be replaced by means for performing one or more of the functions of the structural feature whether that function or those functions are explicitly or implicitly described.

In some but not necessarily all examples, an loT device (ME) 302 as described herein is configured to communicate data from the ME 302 with or without local storage of the data in a memory 306 at the ME 302 and with or without local processing of the data by circuitry or processors at the ME 302.

The data may, for example, be measurement data from sensors or data produced by the processing of measurement data from sensors. The loT device may comprise sensors for sensing an environment external to the loT device. Examples of sensors include, for example, pressure sensors, temperature sensors, mechanical sensors, chemical sensors, biological sensors, optical sensors or the like.

The data may be stored in processed or unprocessed format remotely at one or more devices such as the manufacturer 300 or service provider 301.

The data may be processed remotely at one or more devices 300, 301. The data may be partially processed locally and partially processed remotely at one or more devices.

The above described examples find application as enabling components of: automotive systems; telecommunication systems; electronic systems including consumer electronic products; distributed computing systems; media systems for generating or rendering media content including audio, visual and audio visual content and mixed, mediated, virtual and/or augmented reality; personal systems including personal health systems or personal fitness systems; navigation systems; user interfaces also known as human machine interfaces; networks including cellular, non-cellular, and optical networks; ad-hoc networks; the internet; the internet of things; virtualized networks; and related software and services.

The term 'comprise' is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising Y indicates that X may comprise only one Y or may comprise more than one Y. If it is intended to use 'comprise' with an exclusive meaning then it will be made clear in the context by referring to "comprising only one.." or by using "consisting".

In this description, reference has been made to various examples. The description of features or functions in relation to an example indicates that those features or functions are present in that example. The use of the term 'example' or 'for example' or 'can' or 'may' in the text denotes, whether explicitly stated or not, that such features or functions are present in at least the described example, whether described as an example or not, and that they can be, but are not necessarily, present in some of or all other examples. Thus 'example', 'for example', 'can' or 'may' refers to a particular instance in a class of examples. A property of the instance can be a property of only that instance or a property of the class or a property of a sub-class of the class that includes some but not all of the instances in the class. It is therefore implicitly disclosed that a feature described with reference to one example but not with reference to another example, can where possible be used in that other example as part of a working combination but does not necessarily have to be used in that other example.

Although examples have been described in the preceding paragraphs with reference to various examples, it should be appreciated that modifications to the examples given can be made without departing from the scope of the claims.

Features described in the preceding description may be used in combinations other than the combinations explicitly described above.

Although functions have been described with reference to certain features, those functions may be performable by other features whether described or not.

Although features have been described with reference to certain examples, those features may also be present in other examples whether described or not.

The term 'a' or 'the' is used in this document with an inclusive not an exclusive meaning. That is any reference to X comprising a/the Y indicates that X may comprise only one Y or may comprise more than one Y unless the context clearly indicates the contrary. If it is intended to use a' or 'the' with an exclusive meaning then it will be made clear in the context. In some circumstances the use of 'at least one' or 'one or more' may be used to emphasis an inclusive meaning but the absence of these terms should not be taken to infer any exclusive meaning.

The presence of a feature (or combination of features) in a claim is a reference to that feature or (combination of features) itself and also to features that achieve substantially the same technical effect (equivalent features). The equivalent features include, for example, features that are variants and achieve substantially the same result in substantially the same way. The equivalent features include, for example, features that perform substantially the same function, in substantially the same way to achieve substantially the same result.

In this description, reference has been made to various examples using adjectives or adjectival phrases to describe characteristics of the examples. Such a description of a characteristic in relation to an example indicates that the characteristic is present in some examples exactly as described and is present in other examples substantially as described.

Whilst endeavoring in the foregoing specification to draw attention to those features believed to be of importance it should be understood that the Applicant may seek protection via the claims in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not emphasis has been placed thereon.

I/we claim:

Claims

CLAIMS1. An Internet of Things distributed network configured to enable end-to-end non-IF data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.
2. The Internet of Things distributed network of claim 1, wherein the persistent subscriber identifier is a cellular subscriber identifier.
3. The Internet of Things distributed network of claim 1 or 2, wherein the persistent subscriber identifier is at least part of an international mobile subscriber identity and/or a mobile station international subscriber directory number.
4. The Internet of Things distributed network of any preceding claim, wherein a source of the message has an associated persistent subscriber identifier comprising at least one digit encoded as a hexadecimal character.
5. The Internet of Things distributed network of claim 4, wherein the associated persistent subscriber identifier is comprised in a profile of a subscriber identity module of the source.
6. The Internet of Things distributed network of claim 5, wherein the subscriber identity module is an embedded or integrated subscriber identity module and wherein the profile is a preloaded profile.
7. The Internet of Things distributed network of any preceding claim, wherein the message is a machine-to-machine message.
8. The Internet of Things distributed network of any preceding claim, wherein the message is routed via a visited network in a roaming context.
9. The Internet of Things distributed network of claim 8, wherein the visited network comprises a core network and a radio access network.
10. The Internet of Things distributed network of claim 8 or 9, wherein the visited network is configured to determine a home network using the persistent subscriber identifier, and route the message via the home network.
11. The Internet of Things distributed network of any preceding claim, wherein the message is routed to the destination via a home network, wherein the home network comprises a core network without a radio access network.
12. The Internet of Things distributed network of claim 11, wherein the home network comprises a cloud core network.
13. The Internet of Things distributed network of claim 10, 11 or 12, wherein the home network is configured to provision persistent subscriber identifiers each having at least one hexadecimal digit.
14. A method of communicating in an Internet of Things distributed network, the method comprising: enabling end-to-end non-IF data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.
15. Computer software that, when executed, causes a method according to claim 14 to be performed.
16. An Internet of Things distributed network apparatus comprising: means for enabling end-to-end non-IF data delivery of a message addressed to a destination using a persistent subscriber identifier, wherein the persistent subscriber identifier comprises at least one digit encoded as a hexadecimal character.
17. The apparatus of claim 16, wherein the apparatus is a mobile equipment configured as an Internet of Things device.
18. The apparatus of claim 16, wherein the apparatus is a core network entity.