阅读说明：本技术 具有因特网协议的助听器系统 (Hearing aid system with internet protocol ) 是由 B·科勒门森 于 2021-06-02 设计创作，主要内容包括：本申请公开了具有因特网协议的助听器系统,所述助听器系统(602,702,802,1002,3002)包括至少第一助听器(604,606,704,706,804,806,1004,1006,3004,3006),其中所述第一助听器配置成基于协议栈(100,400,500,900,1100,1200,1300,1400,1500,1600,1700,1800,1900,2900)建立与远程实体(612,812,1012,3012)的、经因特网的通信链路,其中所述协议栈包括因特网协议与基于蓝牙的协议的组合,所述协议栈实施在所述第一助听器中。(The present application discloses a hearing aid system with internet protocol, the hearing aid system (602,702,802,1002,3002) comprising at least a first hearing aid (604,606,704,706,804,806,1004,1006,3004,3006), wherein the first hearing aid is configured to establish a communication link with a remote entity (612,812,1012,3012) via the internet based on a protocol stack (100,400,500,900,1100,1200,1300,1400,1500,1600,1700,1800,1900,2900), wherein the protocol stack comprises a combination of internet protocol and bluetooth based protocol, the protocol stack being implemented in the first hearing aid.)

1. A hearing aid system (602,702,802,1002,3002) comprising at least a first hearing aid (604,606,704,706,804,806,1004,1006,3004,3006), wherein the first hearing aid is configured to establish a communication link over the internet with a remote entity (612,812,1012,3012) based on a protocol stack (100,400,500,900,1100,1200,1300,1400,1500,1600,1700,1800,1900,2900), wherein the protocol stack comprises a combination of internet protocols and bluetooth based protocols, the protocol stack being implemented in the first hearing aid.

2. The hearing aid system according to claim 1, wherein the internet protocol is internet protocol version 4, IPv4) or internet protocol version 6, IPv 6.

3. The hearing aid system according to claim 1, wherein the protocol stack comprises one or more of:

an application layer (105,406,506,905,1105,1205,1305,1405,1505,1605,1705,1805,1905,2905) configured to process user data and/or control data;

a transport layer (104,405,505,904,1104,1204,1304,1404,1504,1604,1704,1804,1904,2904) configured to establish a connection between the first hearing aid and a remote entity;

a network layer (103,404,403,504,503,503,903,1103,1203,1303,1403,1503,1603,1703,1803,1903,2903) comprising the internet protocol configured to connect the first hearing aid and a remote entity;

a data link layer (102,402,502,902,1102,1202,1302,1402,1502,1602,1702,1802,1902,2902) configured to format data received or transmitted over a physical communication medium;

a physical layer (101,401,501,901,1101,1201,1301,1401,1501,1601,1701,1801,1901,2901) configured to transmit and/or receive data via a physical communication medium.

4. The hearing aid system according to claim 3, wherein the physical layer of the protocol stack (100,400,500,900,1100,1200,1300,1400,1500,1600,1700,1800,1900,2900) comprises a Bluetooth based protocol and the data link layer of the protocol stack (100,400,500,900,1100,1200,1300,1400,1500,1600,1700,1800,1900,2900) comprises a combination of the Bluetooth based protocol and the Internet protocol.

5. The hearing aid system according to claim 1, wherein

The Bluetooth-based protocol is Bluetooth, a Bluetooth low energy protocol and/or a Bluetooth network encapsulation protocol; and

the Internet protocol is as follows:

a wireless local area network protocol WLAN conforming to the IEEE 802.11 standard; or

A wireless personal area network protocol WPAN conforming to the IEEE802.15 standard; or

A low power wide area network protocol LPWAN; or

And UWB conforming to the IEEE802.15.4a standard and/or the IEEE 802.11ah standard.

6. The hearing aid system according to claim 1, wherein the first hearing aid (604,606,704,706,804,806,1004,1006,3004,3006) is configured to perform one or more of:

receiving an audio stream from a remote entity (612,812,1012,3012) over the communication link;

receiving fitting data from a remote entity (612,812,1012,3012) over the communication link;

receiving a firmware update from a remote entity (612,812,1012,3012) via the communication link;

transmitting the sensor data recorded at the hearing aid system to a remote entity via the communication link (612,812,1012,3012);

receiving and/or transmitting optimization data of a neural network via the communication link;

receiving and/or transmitting IFTTT data via the communication link.

7. The hearing aid system according to claim 1, further comprising at least a second hearing aid, wherein the first and second hearing aids (604,606,704,706,804,806,1004,1006,3004,3006) are configured to communicate with each other.

8. The hearing aid system according to claim 7, wherein at least one hearing aid (604,606,704,706,804,806,1004,1006,3004,3006) is configured to relay data received from a remote entity (612,812,1012,3012) via the communication link to a respective other hearing aid and/or to relay data received from a respective other hearing aid via the communication link to a remote entity (612,812,1012,3012).

9. A system, comprising:

the hearing aid system (602,702,802,1002,3002) of any one of claims 1-8; and

a remote entity (612,812,1012,3012).

10. The system of claim 9, further comprising:

a local portable or stationary auxiliary device (608,610,710,810,1010,3010) of the hearing aid system (602,702,802,1002,3002) providing a routing function for the communication link between the first hearing aid and a remote entity (612,812,1012,3012).

11. A method performed by at least a first hearing aid of a hearing aid system, the method comprising:

establishing a communication link with a remote entity via the internet based on a protocol stack, wherein the protocol stack comprises an internet protocol, the protocol stack being implemented in the first hearing aid.

12. A computer-readable storage medium, in which a computer program is stored which, when executed by a processor, causes at least one device to carry out the method according to claim 11.

Technical Field

The present invention relates to the field of hearing aid systems. More particularly, the invention relates to the exchange of data of a hearing aid system with a remote entity and protocols for the aforementioned exchange of data.

Background

Currently, for communication between a hearing aid system and a remote server, e.g. fitting a hearing aid, providing or collecting data, updating firmware of the hearing aid system, streaming audio content, etc., a local auxiliary user device (such as a smartphone, tablet or personal computer) with special (usually proprietary or vendor specific) software provided by the hearing aid vendor is required. The device or software is connected to the hearing instrument either directly or via a gateway. In such systems, the wireless technology standard for locally connecting auxiliary devices to the hearing aid system is typically Bluetooth (BT) or bluetooth low energy (bluetooth LE) in combination with an Asynchronous Connectionless (ACL) protocol for the transmission link. The communication between the auxiliary user equipment and the remote server is then based on an internet/internet protocol, such as version 4(IPv4) or version 6(IPv 6).

The above described method has the advantage that the connection established by the hearing aid system (bluetooth or bluetooth LE) requires only little power, since these devices are typically battery powered devices. However, such systems have the disadvantage that a local auxiliary user device is always required and that specific software must be installed on the device to act as a translator between the hearing aid system and the remote server.

Accordingly, there is a need to provide a solution that overcomes at least some of the above-mentioned deficiencies. In particular, there is a need to provide a solution that allows low energy connection to a hearing aid system while having a high degree of flexibility in connecting to a remote entity, such as a remote server.

Disclosure of Invention

According to a first exemplary aspect, a hearing aid system is disclosed, comprising at least a first hearing aid. The first hearing aid may be configured to establish a communication link with a remote entity via the internet based on a protocol stack. The protocol stack may comprise a combination of internet protocol and bluetooth based protocol, which may be implemented in the first hearing aid.

The components of the hearing aid system or of the respective hearing aid for performing the above-described functions may typically be implemented in hardware and/or software. The hearing aid system or the corresponding hearing aid may for example comprise: at least one processor for executing a computer program to perform desired functions, at least one memory storing program code, or both. Alternatively, they may comprise, for example, circuitry designed to perform the required function, for example in a chipset or chip, such as an integrated circuit. In general, a hearing aid system or hearing aid may comprise, for example, one or more processing units or processors.

In an example, the hearing aid system, in particular the respective hearing aid, may comprise at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the hearing aid system at least to perform and/or control the respective function. However, the hearing aid system may also comprise one or more further elements.

According to a second exemplary aspect, a system is disclosed, the system comprising a hearing aid system according to the first aspect and a remote entity.

According to a third exemplary aspect, a method performed by at least a first hearing aid of a hearing aid system is disclosed. In particular, the hearing aid system may be a hearing aid system according to the first aspect. The method may include establishing a communication link with a remote entity via the internet based on a protocol stack. The protocol stack may comprise an internet protocol and the protocol stack may be implemented in the first hearing aid.

As indicated above, the method may be performed and/or controlled by a first hearing aid of the hearing aid system. However, as will be described in more detail below, the method may also be performed by further devices of the hearing aid system and/or by further devices, such as a remote entity, e.g. a server or a cloud server, which together perform the method.

According to a fourth exemplary aspect, a computer program is disclosed, which, when executed by a processor, causes an apparatus to perform and/or control the steps of the method according to the third aspect.

The computer program may be stored on a computer readable storage medium, in particular a tangible and/or non-transitory medium. The computer readable storage medium may be, for example, a memory or the like. The computer program may be stored in the form of instructions that encode a computer-readable storage medium. The computer-readable storage medium may be used for participating in the operation of the device, such as an internal or external memory, e.g. a read-only memory (ROM), a random-access memory (RAM), a hard disk of a computer, or may be used for distributing a computer program, such as an optical disk.

According to a fifth exemplary aspect, a non-transitory computer-readable storage medium is disclosed, in which a computer program is stored which, when executed by a processor, causes at least one device to perform the method according to the third aspect. The computer readable medium comprises a computer storage medium adapted to store a computer program comprising program code to, when the computer program is run on a processing system, cause the data processing system to perform at least a part (e.g., most or all) of the steps of a method described herein and defined in the claims.

By way of example, and not limitation, the aforementioned tangible computer-readable media can comprise RAM, ROM, and/or EEPROM, or any other medium that can be used to execute or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media. In addition to being stored on a tangible medium, a computer program may also be transmitted over a transmission medium such as a wired or wireless link or a network such as the internet and loaded into a data processing system to be executed at a location other than the tangible medium.

In the following, further exemplary features of all aspects of the invention will be described in more detail.

A hearing aid system is generally understood to comprise a hearing aid (which may also be referred to as a hearing device, a hearing instrument or a hearing aid device) adapted to improve or enhance the hearing ability of a user by receiving acoustic signals from the user's environment, generating corresponding audio signals, possibly modifying the audio signals, and providing the possibly modified audio signals as audible signals to at least one ear of the user. "improving or enhancing the hearing ability of a user" may include compensating for a particular hearing loss of an individual user. "hearing aid" may also refer to a device such as an audible headset, an earphone or a headset adapted to electronically receive an audio signal, possibly modify the audio signal, and provide the possibly modified audio signal as an audible signal to at least one ear of a user. The audible signal may be provided, for example, in the form of: acoustic signals radiated into the user's outer ear, acoustic signals transmitted as mechanical vibrations to the user's inner ear through the bony structure of the user's head and/or through portions of the middle ear, and electrical signals transmitted directly or indirectly to the user's cochlear nerve and/or auditory cortex.

The hearing aids of the hearing system are adapted to be worn in any known manner. This may include i) arranging the unit of the hearing system behind the ear (with a tube to direct the air-borne sound signal into the ear canal or with a receiver/speaker arranged close to or in the ear canal and connected (or wirelessly connected) to the unit behind the ear by a wire, as in a behind the ear type hearing aid); and/or ii) arranging the hearing aid wholly or partly in the pinna and/or in the ear canal, such as in an in-the-ear hearing aid or an in-the-canal/deep-in-the-canal hearing aid; or iii) attaching the unit of the hearing aid to a fixture implanted in the skull bone, such as in a bone anchored hearing aid or cochlear implant; or iv) implanting the unit of the hearing aid as a whole or as a partially implanted unit, such as in a bone anchored hearing aid or a cochlear implant. The hearing aid may be implemented in a single unit (housing) or may be implemented in a plurality of units individually connected to each other.

In general, "hearing aid system" refers to a system comprising one or two hearing aids. By "binaural hearing aid system" is meant a system comprising two hearing aids, wherein the respective hearing aids are adapted to provide an audible signal to both ears of a user in cooperation. The hearing aid system or binaural hearing aid system may further comprise one or more auxiliary devices which communicate with the at least one hearing aid and influence the operation of the hearing aid and/or benefit from the function of the hearing aid. A wired or wireless communication link is established between at least one hearing aid and the accessory device to enable information (such as control and status signals, possibly audio signals) to be exchanged therebetween. The auxiliary device may comprise at least one of: a remote control, a remote microphone, an audio gateway device, a wireless communication device such as a mobile phone (e.g., a smart phone), a tablet or another device that includes a graphical interface, a broadcast system, a car audio system, a music player, or a combination thereof. In particular, in the case of an audio gateway device, the device may be adapted to receive a plurality of audio signals, such as from an entertainment apparatus, e.g. a TV or a music player, from a telephone apparatus, e.g. a mobile phone, or from a computer, e.g. a PC. The auxiliary device may further be adapted to (e.g. enable a user) select and/or combine appropriate ones of the received audio signals (or signal combinations) for transmission to the at least one hearing aid. In particular, in the case of a remote control, the auxiliary device may be adapted to control the function and/or operation of at least one hearing aid. The functionality of the remote control may also be implemented in a smart phone or other (e.g. portable) electronic device, which may run an Application (APP) controlling the functionality of at least one hearing aid.

In case the hearing aid system comprises one or more auxiliary devices, a communication link may be established from the hearing aid system to the remote entity, from the hearing aids of the hearing aid system via e.g. the local auxiliary devices and the internet to the remote entity.

In general, a hearing aid may specifically comprise i) an input unit, such as a microphone, for receiving acoustic signals from around the user and providing a corresponding input audio signal; and/or ii) a receiving unit for electronically receiving an input audio signal. The hearing aid may further comprise a signal processing unit for processing the input audio signal and an output unit for providing an audible signal to the user based on the processed audio signal.

The input unit may comprise a plurality of input microphones, for example for providing direction dependent audio signal processing. The aforementioned directional microphone system is adapted to (relatively) enhance a target sound source of a plurality of sound sources in the user's environment and/or attenuate other sound sources (e.g. noise). In one aspect, the directional system is adapted to detect (e.g. adaptively detect) from which direction a particular part of the microphone signal originates. This can be achieved using conventionally known methods. The signal processing unit may comprise an amplifier adapted to apply a frequency dependent gain to the input audio signal. The signal processing unit may also be adapted to provide other suitable functions such as compression, noise reduction, etc. The output unit may comprise an output transducer such as a speaker/receiver for providing air borne acoustic signals transcutaneously or dermally to the skull bone or a vibrator for providing structure borne or liquid borne acoustic signals. In some hearing aids, the output unit may comprise one or more output electrodes for providing an electrical signal, such as in a cochlear implant.

The aforementioned cochlear implant may comprise: i) an external part for picking up and processing sound from the environment, determining a pulse sequence for electrode stimulation from the current input sound; ii) (typically wireless, e.g. inductive) communication link for simultaneously communicating information about the stimulation sequence and energy to the implanted portion; iii) an implanted portion that enables stimulation to be generated and applied to a plurality of electrodes that can be implanted at different locations of the cochlea to allow stimulation of different frequencies of the auditory frequency range. Such systems are described for example in US4,207,441 and US4,532,930.

In one example, the hearing aid comprises a multi-electrode array, for example in the form of a cradle comprising a plurality of electrodes adapted to be located in the cochlea near the auditory nerve of the user. The cradle is preferably made of a soft material to enable proper positioning of the electrode in the cochlea so that the electrode can be inserted into the subject's cochlea. Preferably, the individual electrodes are spatially distributed along the length of the cradle to provide a corresponding spatial distribution along the cochlear nerve in the cochlea when the cradle is inserted into the cochlea.

The configuration of the hearing aid to establish a communication link via the internet may generally be understood as that the hearing aid may establish a telecommunication link via a telecommunication/telecommunication network. Wherein a link is understood to be or comprise a communication channel connecting two or more devices, i.e. a hearing aid and a remote entity, for data transmission purposes. The link may be a dedicated physical link or a virtual circuit using one or more physical links or sharing a physical link with other telecommunications links. The link may be based on one of several types of information transmission paths, such as those provided by communications satellites, terrestrial radio communications infrastructure, and computer networks connecting more than two points. In particular, a link may be understood as a node connecting a network. In particular, a link may be understood as or comprise a logical link. For example, a link may be a data link, an uplink, a downlink, and/or a point-to-point link. In particular, a point-to-point link is understood to be a dedicated link connecting two communication points (e.g. two nodes of a network).

Establishing a communication link with a remote entity via the internet may be understood as establishing a communication link with at least one remote entity. In particular, the remote entity (or remote entities) may be or include a server, a plurality of (e.g., distributed) servers, such as a computer cloud. In particular, the remote entity may be controlled and/or operated by the hearing aid vendor.

In particular, a protocol stack is understood to refer to an implementation of a set or family of computer networking protocols. In particular, the Protocol stack may be a Protocol stack conforming (at least in part) to the Internet Protocol Suite (Internet Protocol Suite) and/or the open systems interconnection model (OSI model).

The internet protocol suite is a conceptual model and a set of communication protocols used in the internet and similar computer networks. Due to the two basic protocols in this set, Transmission Control Protocol (TCP) and Internet Protocol (IP), it is often referred to as TCP/IP, or User Datagram Protocol (UDP), real-time transport protocol (RTP). The internet protocol suite provides end-to-end data communication that specifies how data should be packed, addressed, transmitted, routed, and received. This functionality is basically organized into four abstraction layers that classify the relevant protocols according to the networking domain involved.

The OSI model is a conceptual model that characterizes and standardizes the communication functions of a telecommunications or computing system, regardless of its internal structure and technology. According to this model, a communication system can be divided into seven abstraction layers. The initial version of the model has seven layers. Generally, one layer serves layers above it and accepts services of layers below it. For example, a layer providing error-free communication across a network provides a path required by an application above it, while it invokes an adjacent lower layer to send and receive packets that constitute the contents of the path.

The protocol stack may include (at least) internet protocol. The Internet Protocol (IP) is understood to be the protocol of the internet layer of the TCP/IP model. The internet protocol may be the primary communication protocol in the internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, essentially establishing the internet. The internet protocol may have the task of uniquely transferring packets from a source host to a destination host based on the IP address in the packet header. For this purpose, the internet protocol defines a packet structure that encapsulates the data to be transmitted. It also defines the addressing method used to label datagrams with source and destination information.

Datagrams may be self-contained, stand-alone data entities that carry sufficient information to be routed from a source computer to a destination computer without relying on earlier exchanges between the source and destination computers and the transport network.

In particular, the internet protocol may be internet protocol version 4(IPv4) or its successor, internet protocol version 6(IPv 6). However, in general, the internet protocol may be any other version or future version of the internet protocol.

As will be described in detail below, the protocol stack may, and typically does, include additional layers and/or protocols.

A protocol stack implementation in a hearing aid is to be understood as meaning that the hearing aid itself utilizes a protocol stack and the corresponding internet protocol. In other words, the hearing aid is capable of operating according to the internet protocol and for example of processing (such as generating and/or decoding) data packets (for example by encapsulating and/or extracting data to be transmitted/received) according to a packet structure of the internet protocol.

There is provided a hearing aid configured to establish a communication link over the internet with a remote entity based on a protocol stack, wherein the protocol stack comprises an internet protocol, and the protocol stack is implemented in a first hearing aid such that the communication link is formed between the hearing aid and the remote entity without the need for vendor specific applications or software on the accessory device. The device does not have to be installed with the aforementioned software while still making possible the use of auxiliary devices. An auxiliary user device such as a smart phone or a computer may in some embodiments not even be required and the hearing aid may for example communicate directly with the router.

The communication link between the first hearing aid and the remote entity via the internet may thus be regarded as a direct internet protocol link to the remote entity. To this end, both the remote entity and the hearing aid may comprise protocol stack layers implementing internet protocols thus enabling the exchange of data packets according to the internet protocols.

The communication link between the first hearing aid and the remote entity via the internet may be established via an internet service provider. Thus, the communication between the hearing aid and the internet service provider may likewise be based on a protocol stack comprising internet protocols. As described above, a direct IP link may thus be established from the hearing aid to the remote entity via the internet service provider.

The communication link between the first hearing aid and the remote entity via the internet may be an end-to-end internet protocol link. In particular, this may be understood as the application specific features residing in the communicating end nodes of the network (i.e. the hearing aid and the remote entity) rather than in intermediate nodes (present for establishing the network) such as gateways and routers.

As already mentioned, the internet protocol may in particular be internet protocol version 4, i.e. IPv4, or internet protocol version 6, i.e. IPv6, or any future version of the internet protocol. The first major version of the internet protocol, internet protocol version 4(IPv4), is still currently the predominant protocol for the internet. Its successor version is internet protocol version 6(IPv6), which has been increasingly deployed over the public internet since the past years.

The internet protocol stack may include an application layer. In general, the application layer may contain the communication protocols and interface methods used in process-to-process communication across an internet protocol computer network. The application layer may standardize communication and establish host-to-host data transfer channels and manage data exchange in a client-server or peer-to-peer network according to a transport layer protocol. Examples of protocols at this layer (in the TCP/IP model) are FTP, HTTP or HTTPS, IMAP, SMTP, SSH, TLS/SSL. The application layer may thus be considered responsible for processing user data and/or control data, such as audio data, encoded audio data, audio control data and/or non-audio data.

The internet protocol stack may include a transport layer. The protocol of this layer (in the IP model) provides host-to-host, broadcast and/or multicast communication services for applications. Which may provide services such as connection-oriented communication, reliability, flow control, and multiplexing. Examples of protocols for this layer are TCP and UDP. In particular, the transport layer may thus be considered to be responsible for establishing a connection between the first hearing aid and the remote entity. The connection may be an IP connection or an IP link between the first hearing aid and the remote entity.

The internet protocol stack may include a network layer including internet protocol. In particular, the network layer may be the Internet layer (in the TCP/IP model). The internet layer is typically used to pass network packets from an originating host to a destination host (typically specified by an IP address) across network boundaries, if desired. Examples of protocols at this layer and examples of internet protocols are IPv4 or IPv6 already mentioned. Thus, in particular, the network layer or the internet layer may be considered as being responsible for connecting the first hearing aid and the remote entity.

The internet protocol stack may include a data link layer. The link layer may include a set of methods and communication protocols that are limited to links to which the hosts are physically connected. The link layer may define methods and standards that operate only between adjacent network nodes of a network segment. The data link layer may include sub-layers such as LLC or MAC. Thus, in particular, the data link layer may be responsible for formatting data received or transmitted over the physical communication medium.

The internet protocol stack may include a physical layer, in particular, for transmitting and/or receiving data via a physical communication medium. The physical layer may be implemented by a PHY chip, for example. In particular, the physical layer consists of electronic circuit transmission techniques of the network. Which is the basic layer under higher level functions in the network and can be implemented by different hardware techniques. In particular, the physical layer may define means for transmitting raw bits over the physical data link connecting the network nodes. For example, a bit stream may be grouped into codewords or symbols and converted into physical signals for transmission over a transmission medium. The physical layer can be viewed as providing an electrical, mechanical, and process interface to a transmission medium.

The protocol stack may comprise or be based on the so-called bluetooth network encapsulation protocol BNEP. Bluetooth Network Encapsulation Protocol (BNEP) may be understood as a protocol that encapsulates packets from one or more (e.g., a plurality of different) other networking protocols into a bluetooth data link layer, which may then be directly transmitted over a bluetooth protocol, for example, by utilizing bluetooth logical link control and application layer protocol (L2 CAP). L2CAP may provide a data link layer for bluetooth. Specifically, BNEP may remove and replace the ethernet header with a BNEP header. However, this enables the ethernet payload to remain unchanged. Finally, the BNEP header and the Ethernet payload may be encapsulated by L2CAP and may be transmitted over the Bluetooth medium.

The protocol stack may comprise or be based on an internet protocol Support profile ipsp (internet Bluetooth Support profile), such as internet protocol version 6(IPv6) (6 lobtel) over Bluetooth (R) low power consumption or any later version of internet protocol over Bluetooth (R) low power consumption. Internet Protocol Support Profiles (IPSP) enable devices to discover and communicate with other IPSP enabled devices, such as secondary user equipment, e.g., smart phones or IPSP routers. Communication between devices supporting IPSP may be performed using IPv6 packets transmitted via bluetooth low energy. Among them, the Internet Protocol Support Service (IPSS), generic attribute profile (GATT), and attribute protocol (ATT) may be used only for service discovery, and the Generic Access Profile (GAP) may be used for service discovery and connection setting.

Both of the above methods enable the use of widely supported and implemented low power transmission technologies, such as the bluetooth or bluetooth LE standards for transmitting data, while at the same time an internet protocol may be implemented and thus a direct IP link from the hearing aid to the remote entity.

The protocol stack may include or be based on a wireless local area network protocol WLAN conforming to the IEEE 802.11 standard. The advantage of this technique is that it is also widely supported and implemented in many devices and routers.

To provide a particular power efficient approach, the protocol stack may also include or be based on a Low Power Wide Area Network (LPWAN) protocol. LPWANs are generally designed to enable long distance communication at low bit rates between connected (and typically battery-powered) objects. Low power, low bit rate and planned usage distinguish this type of network from wireless LANs, which are designed to use more power to connect users or business partners and carry more data. In one example, the LPWAN data rate may be in the range of 0.3 to 50kbit/s per channel.

In particular, as mentioned above, the protocol stack may particularly comprise protocols (such as BNEP, 6 lobble, 6LOWPAN, RFC 7668-IPv6 with low power consumption via bluetooth (R)) configured to remove (IP/ethernet) headers and/or encapsulate IP packets of internet protocol processes.

While the data link layer and/or the physical layer of the protocol stack may be based on a WLAN, which is a wireless local area network protocol compliant with the IEEE 802.11 standard, the data link layer and/or the physical layer of the protocol stack may also be based on a bluetooth or bluetooth LE protocol, a WPAN, which is a wireless personal area network protocol compliant with the IEEE802.15 standard, a LPWAN, a low power wide area network, and/or an ultra-wideband UWB, which is compliant with the IEEE802.15.4a standard.

The first hearing aid may be configured to receive an audio stream from a remote entity via said communication link. For example, the remote server may stream music or other audio directly to the hearing aid. Additionally or alternatively, the hearing aid may transmit an audio stream to a remote entity (e.g. for control commands or a two-way conversation) via a communication link.

The first hearing aid may be configured to receive fitting data from a remote entity via said communication link. Current hearing aids are often capable of remote fitting via a wireless connection. However, if the hearing aid now supports internet protocols such as IPv4 or IPv6 and a bearer such as bluetooth, any device (phone/tablet/personal computer) that can be used as an IP border router and has a bearer compatible with the bearer supported by the hearing aid can be used as a fitting device without any dedicated device or dedicated software.

The first hearing aid may be configured to receive a firmware update from the remote entity via said communication link. The advantages described above apply equally to Device Firmware Update (DFU) scenarios.

The first hearing aid may be configured to transmit the sensor data recorded at the hearing aid system to a remote entity via said communication link. Examples of the aforementioned sensors are microphones, heart rate sensors, electroencephalogram (EEG) sensors, and the like. The sensor data may be first stored at the hearing aid system after logging (e.g. in a non-volatile memory) or sent directly to a remote entity after logging.

The first hearing aid may be configured to receive and/or transmit optimization data of the neural network via said communication link. The optimization data may be or include, for example, audio data representing a user spoken command or audible audio recorded from the environment.

The first hearing aid may be configured to receive and/or transmit IFTTT data via said communication link.

Ifttt (if this that is) is a programming condition statement that enables the programming of the first hearing aid and/or other device to respond to an event.

Depending on the type of data sent and/or received via the communication link, the protocol stack, and in particular the application layer, may be adapted accordingly to be able to process the corresponding data.

The hearing aid system may further comprise at least a second hearing aid, wherein the first and second hearing aids are configured to communicate with each other. In particular, the first and second hearing aids may be configured to exchange data of the above mentioned type, such as audio data, fitting data, sensor data, optimization data, etc. The communication between the first and second hearing aid may be implemented by the above mentioned technologies, such as bluetooth, bluetooth LE or another proprietary RF or magnetic link.

At least one hearing aid may be configured to relay data received from a remote entity via a communication link to a respective other hearing aid and/or to relay data received from a respective other hearing aid via a communication link to a remote entity. This has the advantage that only one of the hearing aids needs to be within the coverage area of the respective accessory, access point or router. Again, this may enable only one of the hearing aids to implement a protocol stack comprising internet protocols at one of the hearing aids and to enable the hearing aid to connect to an access point or router.

The system according to the second aspect may further comprise a portable or stationary auxiliary device local to the hearing aid system providing a routing function for the communication link between the first hearing aid (and optionally the second hearing aid) and the remote entity. As already described, the portable or stationary auxiliary device may be a smartphone, tablet, computer or router. However, in contrast to the prior art, the auxiliary device does not require any vendor-specific software in order to provide routing functionality for the communication link. Instead, the accessory only needs to support the protocol used by the hearing aid to establish the internet protocol link.

For example, in a preferred approach, a protocol stack at the hearing aid, such as a 6 lobble/6 LoWPAN adaptation layer, may be configured to remove the IP header of the corresponding IP packet generated by the internet protocol at the hearing aid and replace it with another header to transmit the data to the accessory (e.g. via bluetooth or bluetooth LE standards). The secondary device may then provide an IP header and forward the corresponding data to the remote entity based on the internet protocol as usual.

The above features should be considered disclosed in any combination with each other. Furthermore, the disclosure of any means for performing the method steps should be understood as disclosing corresponding method steps as well, and the disclosure of method steps should be understood as disclosing corresponding means for performing the steps as well.

Drawings

Various aspects of the invention will be best understood from the following detailed description when read in conjunction with the accompanying drawings. For the sake of clarity, the figures are schematic and simplified drawings, which only show details which are necessary for understanding the invention and other details are omitted. Throughout the specification, the same reference numerals are used for the same or corresponding parts. The various features of each aspect may be combined with any or all of the features of the other aspects. These and other aspects, features and/or technical effects will be apparent from and elucidated with reference to the following figures, in which:

FIG. 1 illustrates an exemplary layered IP protocol stack;

FIG. 2 illustrates a TCP header format;

FIG. 3 illustrates a UDP header format;

FIG. 4 shows an exemplary IP stack overview for a classic Bluetooth enabled IP link;

FIG. 5 illustrates an exemplary IP stack overview for low power IP link enablement;

fig. 6 illustrates an exemplary system that enables an end-to-end IP link between a remote entity and a hearing aid system;

fig. 7 shows an exemplary IP link to the hearing aid system and forwarding between hearing aids;

FIG. 8 illustrates an exemplary system with IP streaming and voice assistant capabilities;

FIG. 9 shows an exemplary IP stack configuration for music streaming and voice assistant;

FIG. 10 illustrates an exemplary system for initiating remote fitting with a border router device;

FIG. 11 illustrates an exemplary IP stack configuration for a remote fitting program;

FIG. 12 illustrates an alternative exemplary IP stack configuration for remote fitting;

FIG. 13 illustrates an exemplary IP stack configuration for device firmware updates;

FIG. 14 illustrates an alternative exemplary IP stack configuration for device firmware update;

FIG. 15 illustrates an exemplary IP stack configuration for data collection;

FIG. 16 illustrates an exemplary IP stack configuration for neural network tuning;

FIG. 17 illustrates an alternative exemplary IP stack configuration for neural network tuning;

FIG. 18 illustrates a generic IP communication model with a wireless interface;

FIG. 19 shows an exemplary IP stack with CTPS;

fig. 20 shows a PDU format for CTPS;

fig. 21 shows a payload format for CTPS;

fig. 22 shows a format of a link manager SDU for CTPS;

fig. 23 shows a format of a PDU frame for acknowledgment of CTPS;

fig. 24 shows a format of a new SDU for CTPS;

fig. 25 shows a format of SDU for retransmission of CTPS;

FIG. 26 illustrates exemplary PDU encryption;

FIG. 27 shows a flow chart when receiving an encrypted PDU;

FIG. 28 shows a simplified IP stack with a number of exemplary possible transports;

fig. 29 shows an exemplary end-to-end IP link transmitted via LoRA or WiFi 802.11 ax.

Detailed Description

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. It will be apparent, however, to one skilled in the art that these concepts may be practiced without these specific details. Several aspects of the apparatus and methods are described in terms of various blocks, functional units, modules, elements, circuits, steps, processes, algorithms, and the like (collectively, "elements"). Depending on the particular application, design constraints, or other reasons, these elements may be implemented using electronic hardware, computer programs, or any combination thereof.

The electronic hardware may include micro-electro-mechanical systems (MEMS), (e.g., application-specific) integrated circuits, microprocessors, microcontrollers, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), gating logic, discrete hardware circuits, Printed Circuit Boards (PCBs) (e.g., flexible PCBs), and other suitable hardware configured to perform the various functions described herein, such as sensors for sensing and/or recording physical properties of an environment, device, user, etc. A computer program should be broadly interpreted as instructions, instruction sets, code segments, program code, programs, subroutines, software modules, applications, software packages, routines, subroutines, objects, executables, threads of execution, programs, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or by other names.

Different exemplary protocols that may be used in different aspects of the invention will be described below, and different use cases in which different aspects of the invention may be used will be described.

Fig. 1 shows an exemplary five-layer diagram of a protocol stack 100 including an internet or network layer 103 having internet protocol (thus an "internet protocol stack" or "IP stack") illustrating how successive headers are added by protocols operating at each layer 101 and 105. Each layer 101-105 handles a specific set of issues relating to some aspects of transmitting data between distributed user applications, i.e. applications running on devices (hearing aid systems and remote entities as will be described in more detail below) that are connected to the same or different networks. As the original application data (e.g., user data or control data, as disclosed in the present invention) moves down from the application layer 105 through the plurality of different layers 102 and 104, it is encapsulated (or encapsulated) within the Protocol Data Units (PDUs) generated by each protocol it encounters. The names commonly used to refer to these PDUs tend to vary. For example, at the network layer, they are referred to as packets or datagrams. At the link layer, they are more often referred to as frames.

Data from the application is passed down to the appropriate application layer protocol, which encapsulates the data within a Protocol Data Unit (PDU) by adding some header information. The entire PDU is then passed down to the transport layer protocol and undergoes similar processing. This encapsulation is repeated for the network layer and the link layer. The frames established by the link layer are sent as a bit stream or symbol stream over a physical transmission medium to a (e.g., border) router or network switch.

A description of the functionality of each layer 101-105 that may be employed in a hearing aid system (e.g. hearing aid, accessory) or remote entity according to the present invention is given in the following table.

Different exemplary protocols for these layers 101 and 105 will be described below, which may equally be employed in a hearing aid system (e.g. a hearing aid or an accessory) or a remote entity according to the present invention.

There are several standardized application layer protocols (see, for example, the service name and transport protocol port number registry, www.iana.org/assignments/service-names-port-numbers. The following table shows a profile of an exemplary standardized application layer protocol, which may be employed in various aspects according to the present invention:

two exemplary transport layer protocols in the IP stack are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). The differences between TCP and UDP are provided in the following table:

fig. 2 and 3 show header formats 200, 300 that may be employed in two transport layer protocols, a "transmission control protocol" (TCP) and a "user datagram protocol" (UDP), in a protocol stack according to the present invention.

As already mentioned above, the network layer 103 of fig. 1 comprises the internet protocol. Internet Protocol (IP) involves obtaining datagrams from a source all the way to a destination. Reaching a destination may involve many hops at a router (intermediate node). IP provides the best-effort network layer services whereby connection endpoints (computers, telephones, etc.) form a computer network. IP network services use IP routers (between intermediate nodes) to transport datagrams.

There are generally two appropriately deployed internet protocols or protocols: : internet protocol version 4(IPv4) and internet protocol version 6(IPv 6). IPv4 is a fourth version of the Internet Protocol (IP). IPv4 was the first edition to be deployed in large numbers in 1983. Despite the ongoing deployment of the successor protocol IPv6, most internet traffic is currently routed. IPv4 and IPv6 are described in the internet protocol version 4(IPv4) specification (https:// tools. ietf. org/html/rfc791) and the internet protocol version 6(IPv6) specification (https:// tools. ietf. org/html/rfc2460), respectively.

An important difference between IPv4 and IPv6 is address length, with IPv4 using a 32-bit address scheme allowing a total of 2^32 addresses (over 40 hundred million addresses), and IPv6 using a 128-bit address scheme allowing about 2^128 addresses. With the growth of the internet, it is expected that the number of unused IPv4 addresses will eventually run out, as each device (phone, PC, game console, headset, hearing aid, etc.) connected to the internet requires an address.

The size of the IPv4 header is between 20-60 octets (which may be up to 16 octets depending on the length of the option field), while the IPv6 header is 40 octets, although the extension header may be added as part of the payload field. The extension header is a minimum of 4 octets or more (see, e.g., IPv6 header, https:// en. wikipedia. org/wiki/IPv6_ packet).

Now, to enable a direct IP link between the hearing aid and the remote entity, a protocol stack (IP stack) with internet protocol is supported in the hearing aid.

The preferred method according to the invention employs an IP link within the framework of the bluetooth standard, which will be described in detail in connection with fig. 4 and 5. One option is to use the Bluetooth Network Encapsulation Protocol (BNEP) for classical bluetooth, which is described in the Bluetooth Network Encapsulation Protocol (BNEP) specification (see www.bluetooth.org/docman/handlers/downlink doc. ashxdoc _ id 6552). A corresponding protocol stack 400 is shown in fig. 4. The protocol stack 400 includes: a physical layer 401 with bluetooth radio and bluetooth baseband, a link layer 402 with L2CAP protocol, a network sublayer 403 with BNEP protocol, a network/internet layer 404 (with internet protocols such as IPv4 or IPv6), a transport layer 405 and an application layer 406.

Another option is Internet Protocol Support Profile (IPSP) for bluetooth low energy, illustrated for example at www.bluetooth.org/docman/handlers/downloaddoc. ashxdoc _ id 296307. A corresponding protocol stack 500 is shown in fig. 5. The protocol stack 500 includes a physical layer 501, a link layer 502 containing the L2CAP protocol, a network sublayer 503 with the 6 lobble protocol (now compliant with RFC 7668, referred to as bluetooth (R) low power IPv6), a network/internet layer 504 with internet protocols such as IPv6, a transport layer 505, and an application layer 506. BNEP supports the transmission of IPv4 and IPv6 datagrams, while IPSP supports only IPv6 datagrams.

To save power, low power radio protocols such as bluetooth use small (bearer specific) frame sizes. The frame size depends on the amount of payload and the amount of control (signaling) data needed. Therefore, in low power protocols, it is important to minimize the amount of overhead in data link layer frames.

Referring to fig. 4, when a frame with a message is transmitted, BNEP removes the IP header and replaces it with a BNEP header. When a frame with a message is received, the reverse is true. Finally, the BNEP header and IP payload are encapsulated by the bluetooth logical link control and adaptation protocol (L2CAP) and the subsequent baseband or link layer protocol and transmit the physical medium. BNEP headers are typically between 4 and 16 octets, and their size is significantly reduced compared to IPv4 and IPv6 headers. In general, layer 403 and 406 may be shown as initiating a direct IP link from the hearing aid to a remote entity.

Referring to fig. 5, for IP transport via bluetooth Low Energy (LE), the specification of IPv6 via bluetooth low energy (6 lobtel) (see IPv6 via bluetooth (R) low energy) is used, for example:

-link establishment to an auxiliary device, such as an IPSP router;

neighbor discovery, i.e. other IPSP nodes connected to the same router; and/or

-compressing the IPv6 header between 2 and 20 octets.

In general, layer 503 and 506 may be shown as initiating a direct IP link from the hearing aid to the remote entity.

From this perspective, the assignment of different protocols to different layers may not always be strict and explicit. However, BNEP and 6 lobble are generally considered as sub-layers in the networking layer or adaptation layer, i.e. below the IP protocol.

The BNEP or IPSP stack 400,500 is typically part of an accessory or typical gateway used (i.e., a smartphone, tablet, personal computer, or WiFi/bluetooth combination router with BNEP or IPSP). If BNEP and/or IPSP are now supported in the hearing aid, no vendor specific software is needed on the accessory to access the internet connected server from the hearing aid. A corresponding system for establishing an end-to-end IP link with a remote entity and a hearing aid system is shown in fig. 6.

The system of fig. 6 comprises a hearing aid system 602 with a first hearing aid 604 and a second hearing aid 606. The hearing aid system further comprises an auxiliary device in the form of a mobile device 608 or a router 610. The system 600 also includes a remote server 612. While the hearing aids 604 and/or 606 are physically connected to one or more accessory devices 608 and/or 610 via bluetooth or bluetooth LE, the first and/or second hearing aids 604,606 establish a direct IP link to a remote server 612 via the internet. This may be accomplished by employing a protocol stack such as IP stack 400 or 500 described above. While the connection between the accessory 608,610 and the server 612 is a standard IP-based connection, the IP data in the connection between the hearing aid 604,606 and the accessory is encapsulated in the bluetooth protocol.

Only one of the two hearing aids 604,606 of fig. 6 may have a bluetooth connection (IP link) to the border router. In this case the hearing aids 604,606 with bluetooth connection may relay the IP payload to the other hearing aid by means of a separate connection between the two hearing aids, as illustrated by the hearing aids 704,706 and the border router 710 of the hearing aid system 702 in fig. 7. The connection may also be a bluetooth connection, for example, and a vendor specific connection.

Further options for implementing the IP stack in the hearing aid will be described below.

In the following, different use cases are described, which are enabled by the hearing aid implementing an IP link.

An example of a use case is streaming of audio. A corresponding system 800 is exemplarily shown in fig. 8. The following streaming use cases are possible. As an example, the remote server 812 may stream music directly to the hearing aid. The hearing aids 804,806 of the hearing aid system 802 may synchronize the rendered audio via the connection between the hearing aids based on a time stamp, codec frame number, or both provided by the remote entity (e.g. a server). The connection between the hearing aids 804,806 may be magnetic or RF based. As another example, a two-way conversation may be employed in which an end user speaks with a remotely located person, through a remote server bridge to a voice assistant (e.g., Alexa, Siri, or Google) and/or directly with the (human) voice assistant. As yet another example, the hearing aid may stream audio to the server 812 in one direction, e.g. for control commands. Additionally or alternatively, remote server 812 may notify the user with a one-way stream of audio, such as when there is a (feature) update.

An example of an IP stack 900 with layers 901 and 905 for this use case is shown in fig. 9. In the application layer 905, RTP (real-time transport protocol) is used to transmit encoded audio data, and RTCP (real-time transport protocol control protocol) is used to transmit audio control messages. These protocols are described in the real-time protocol (RTP) and RTP control protocol (RTCP) specifications. UDP is used as the transport protocol in transport layer 904.

Another example of a use case is a fitting procedure. Fig. 10 shows an exemplary system 1000 with a hearing aid system 1002, hearing aids 1004,1006, a border router 1010 and a remote server 1012 for this use case. When using internet protocol at the hearing aid, the benefits of the fitting procedure are as follows: no provisioning gateway (e.g., Noahlink Wireless) is required. To increase the fitting speed, two routers may be used, one for each hearing instrument. During the compounding procedure, the pharmacist may speak with the end user via IP at the same time, as described above in connection with communicating with the assistant.

Current hearing aids are already capable of remote fitting, but they require a wireless connection to a dedicated fitting device or a connection to a mobile phone, tablet or computer, which must contain a dedicated fitting application or fitting software. However, if the hearing aids 1004,1006 support internet protocol IPv4, such as IPv6, and a carrier, such as bluetooth, any accessory device (phone/tablet/PC) that can be used as an IP border router 1010 and has a carrier compatible with the carrier employed by the hearing aid can be used as a fitting device without the need for any dedicated device or dedicated software. During a remote verification session, the pharmacist and the end user may also speak to each other via an IP link (see description above).

Figure 11 shows an exemplary IP stack 1100 with layers 1101 and 1105 for this use case. At the application layer 1105, the fitting application protocol may be used to transport fitting data, RTP may be used to transport encoded audio data, and RTCP may be used to transport audio control messages. At the transport layer 1104, the fitting application protocol may use TCP and the audio application protocol may use UDP. The fitting application protocol may be a vendor-specific or standardized protocol such as the Message Queue Telemetry Transport (MQTT) protocol, described under http:// MQTT.

FIG. 12 is an alternative IP stack configuration 1200 for remote provisioning with layer 1201 and 1205 in which the provisioning protocol uses the constrained application protocol (CoAP), such as illustrated under https:// tools. ietf. org/html/rfc7252, which enables messages to be acknowledged, which enables reliable data communication in the provisioning use case. This is particularly advantageous because all fitting will be reliably transmitted, otherwise the hearing aid may work incorrectly and may even damage the ear of the end user if part of the fitting data is missing.

Yet another example of a use case is a device firmware update. Similar to the remote fitting use case, the hearing aid may perform a Device Firmware Update (DFU) via a wireless connection to a dedicated fitting device or a smartphone, tablet or personal computer containing a dedicated fitting application or fitting software. However, if the hearing aid supports internet protocol IPv4, such as IPv6, and a carrier, such as bluetooth, any accessory device (smartphone, tablet, computer) that can act as an IP border router and has a carrier compatible with the carrier employed by the hearing aid can be used as a fitting device without the need for any dedicated device or dedicated application or software.

Fig. 13 shows an exemplary IP stack configuration 1300 for this use case, with layers 1301 and 1305. At the application layer 1305, the DFU application protocol is used to transport DFU data. Alternatively, a standardized file transfer protocol (such as the protocol mentioned in https:// en. wikipedia. org/wiki/company _ of _ file _ transfer _ protocols) may be used. At the transport layer 1304, TCP may be used.

Fig. 14 shows an alternative IP stack configuration 1400 for a DFU use case, with layers 1401 and 1405, where the DFU protocol uses the constraint application protocol (CoAP). As described above, the protocol enables messages to be acknowledged, which enables reliable data communication in DFU situations. It is desirable that the DFU data be reliably transmitted, otherwise the hearing aid may operate incorrectly and may even damage the end user's ear if part of the DFU data is missing.

Yet another use case is data acquisition. A plurality of different sensors may be implemented in the hearing aid. Examples of the aforementioned sensors are microphones, heart rate sensors or electroencephalogram (EEG) sensors. The hearing aid may read the corresponding sensor output at a normal rate and may store this data in its non-volatile memory in one example. Once the hearing aid is connected to the internet, the recorded sensor data may be uploaded to a remote data acquisition server, as described above. The hearing aid may also transmit the sensor data directly to the data acquisition server when it is connected, without storing the data in its non-volatile memory. Furthermore, the program may be uploaded directly using statistics and hearing aid status information, or the stored data may be uploaded while connected to the internet.

Fig. 15 shows an exemplary IP stack configuration 1500 for a data collection use case, with layers 1501 and 1505. At the application layer 1505, the constraint application protocol (CoAP) already mentioned above is used as a data acquisition application protocol for transmitting acquired data. Alternatively, vendor-specific protocols may be used. At the transport layer 1504, UDP may be used.

Another use case is the optimization or tuning of the neural network in the hearing instrument. The hearing aid may implement a Neural Network (NN) that may need to be optimized or tuned for a specific user. One situation that needs to do this is speech recognition of spoken commands, where the NN of the hearing aid needs to be optimized to better recognize the speech of the hearing aid user. For example, the user may be requested to speak certain commands (e.g. via the NN tuning server), wherein these commands are then recorded by the hearing aid microphone and sent to the NN tuning server together with the NN coefficients. Once the NN (i.e. its coefficients) has been optimized, these coefficients are downloaded to the NN in the hearing aid.

Another situation where the NN of the hearing aid may need to be optimized or tuned may be a specific listening situation, where the NN makes a poor or wrong decision. This situation may be recorded by the microphone of the hearing aid and sent to the NN tuning server together with the NN coefficients. During NN coefficient optimization, a user may be asked questions via an audio IP link. Once the NN coefficients have been optimized, these coefficients are downloaded to the NN in the hearing aid.

Fig. 16 shows an exemplary IP stack configuration 1600 for a neural network tuning use case, with layers 1601-1605. At the application layer 1605, the NN tuning application protocol may be used to transport NN coefficients, while RTP may be used to transport encoded audio data and RTCP may be used to transport audio control messages. At the transport layer 1604, the NN tuning application protocol uses TCP and the audio application protocol uses UDP. The NN tuning application protocol may be a vendor-specific or standardized protocol such as the Message Queue Telemetry Transport (MQTT) protocol already mentioned above.

Fig. 17 shows an alternative IP stack configuration 1700 for neural network tuning, with layers 1701 and 1705, where the NN tuning protocol uses the constrained application protocol (CoAP), which enables messages to be acknowledged, which enables reliable data communication in an exemplary use case of neural network tuning. Neural network data, such as coefficients, should be reliably transmitted, otherwise the hearing aid may operate incorrectly and may even damage the ear of the end user if part of the NN data is corrupted.

Yet another scenario is interaction with a home management system. For example, the hearing instrument may interact with a home management system directly or indirectly via a remote server.

Exemplary aspects of the present invention may also employ a restricted transport protocol with security (CTPS), which will be described in detail below.

When communicating via internet protocol, an application on one device communicates with an application on another device in a unicast scenario, and an application on one device communicates with applications on multiple devices in a multicast scenario. Typically, when two devices (e.g. a hearing aid and a remote entity) communicate via internet protocol, multiple applications on the two devices may communicate with each other. Each message between two corresponding applications is sent as an individual internet protocol packet, i.e. messages from multiple applications directed to the same destination cannot be packed together in one IP packet, however, this is required to minimize IP stack header overhead. The overhead is even greater if security is enabled in one of the slave network layer and the upper layer.

FIG. 18 illustrates an exemplary IP communication model 1800 with a wireless interface, with layers 1801 and 1805, where multiple applications communicate with each other. When one of the devices is a resource-constrained device with a wireless interface, such as a hearing aid, it is inefficient to transmit or receive packets containing IP payloads from individual applications at the wireless interface, because the on-time radio is higher than when application data from multiple applications is packed into larger packets. However, this requires that the application can accept higher latency, since the transmission rate may be reduced when asynchronous data is collected from multiple applications, depending on the transmission frequency and the mode of the multiple applications.

The following section will describe a transport layer protocol that solves the problems outlined above and that can be implemented in a protocol stack according to the invention as described above.

The application layer protocol is often referred to as a service (see, for example, the service name and transport protocol port number registry, www.iana.org/assignments/service-names-port-numbers). Data frames exchanged between the CTPS and the network CTPS layer are called Protocol Data Units (PDUs). FIG. 19 illustrates an exemplary implementation of the IP stack 1900 and its architectural components, specifically layers 1903 and 1905. The CTPS control message protocol module 1906 is responsible for transport layer control messaging, which includes updating or adjusting of parameters related to the link between devices and exchange/updating of security keys. Flow control and retransmission module 1907 with PDU assembly/disassembly handles flow control and retransmission, including storing SDUs in ascending order if PDUs have been received out of order before they are passed on the application layer. PDU assembly and disassembly is handled by the module. The validate, decrypt/encrypt, and CRC module 1908 checks or adds the CRC field, validate PDU, and encrypt/decrypt payload fields.

The CTPS PDU 2000 is shown schematically in fig. 20, and the following table provides an overview of the packet structure.

The following table provides the header field definitions for CTPS PDUs:

fig. 21 shows an exemplary sequence 2100 of four types of frames in the PDU payload 2101: CTPS control message SDU 2102, acknowledged SDU frame 2103, retransmitted SDU frame 2104, and new SDU frame 2105. The header AF and RTX bits indicate whether an acknowledged SDU frame and a retransmitted SDU frame, respectively, are included. The first bit indicates whether the first 3 types are contained in the payload or whether one or more of the first three frame types are not present in the payload.

Fig. 22 schematically shows the format of the CTPS control message SDU 2200 portion of the payload. The first octet field "length" indicates the length of the CTPS control message.

Fig. 23 schematically shows the format of the acknowledged PDU portion 2300 in the payload. The first two octet "PDU number" field indicates the sequence number of the two octet PDU number frame, which contains the lower 16 bits of the sequence number of the acknowledged PDU.

Fig. 24 schematically shows the format of a new SDU frame 2400 in the payload. The first two octet "total length" field indicates the total length of all new SDU frames in octets. An SDU frame begins with a two octet "length" field that specifies the length of the SDU payload in octets. The next field is an octet "port number", which is the port number of the application. However, the port number field may be extended to, for example, 2 octets, whereby TCP and UDP port numbers may be reused.

Fig. 25 schematically shows the format of a retransmitted SDU 2500 in the payload. The first two octets contain the sequence number of the retransmitted PDU. The two octet length field indicates the length of the SDU payload. An octet port number is the port number of the application.

For example, to verify the PDU and encrypt the PDU payload, 128-bit AES (advanced encryption Standard) and CCM (counter mode cipher Block chaining message authentication code) may be used, which is shown in diagram 2600 of FIG. 26, with inputs and outputs provided in the following table. 256-bit AES may be used.

Additional details of the AES-CCM block may be found, for example, in a counter with CBC-MAC, see https:// tools.

With respect to PDU reception and transmission, fig. 27 and 28 show exemplary flowcharts 2700, 2800 of receiving and transmitting PDUs, respectively. The encryption process has been described above.

Both ends need to agree on, for example, a maximum PDU size, transmission interval, and/or security key agreement before data communication can occur. This may occur via configuration at the time of manufacture or via CTPS control message protocol negotiation.

The transmission interval may be configured to have a constant interval; if there is more data to send than the maximum PDU size, with constant interval + additional transmission; if the payload has a defined/negotiated size, with a non-constant interval in which only PDUs are transmitted; if the payload has a defined/negotiated size or if it has not been transmitted for a defined period of time, with a non-constant interval in which only PDUs are transmitted; if there is payload, there is a non-constant interval in which the PDU is transmitted.

When the acknowledgement is initiated, the CTPS will order the received SDUs in ascending order before the SDUs are delivered on the application requesting reliable transmission, the ordering feature being similar to that implemented in TCP. Which transmission interval method to use and whether to request an acknowledgement depends on the application protocol used.

As mentioned above, the protocol stack comprises an internet protocol implemented at the hearing aid, processing and physically transmitting IP packets in layers or sub-layers below the internet protocol using the bluetooth or bluetooth LE standard. However, in general, other protocols or standards than bluetooth may be employed. For example, instead of or in addition to having bluetooth handle the transmission of IP packets in a hearing aid, the handling and transmission may also be implemented via the ieee802.15.4 standard (WPAN), the ieee802.15.4a standard (UWB), any standard of the 802.11 family (WiFi), or LoRaWAN, etc. A simplified IP stack 2900 is shown in FIG. 28, with layers 2901-2905 and a number of possible carriers 2906-2911.

Correspondingly, fig. 29 shows an exemplary system 3000 with a hearing aid system 3002, hearing aids 3004,3006, a LoRA base station and border router 3010 and a remote server 3012. Here, two examples of IP end-to-end links via two different transport protocols (in this example, LoRa or WiFi 802.11ax) are shown.

The structural features of the device described above, detailed in the "detailed description of the embodiments" and defined in the claims, can be combined with the steps of the method of the invention when appropriately substituted by corresponding procedures.

As used herein, the singular forms "a", "an" and "the" include plural forms (i.e., having the meaning "at least one"), unless the context clearly dictates otherwise. It will be further understood that the terms "comprises," "comprising," "includes" and/or "including," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present, unless expressly stated otherwise. The term "and/or" as used herein includes any and all combinations of one or more of the associated listed items. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

It should be appreciated that reference throughout this specification to "one embodiment" or "an aspect" or "may" include features means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention. The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications will be apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Reference to an element in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more. The terms "a", "an", and "the" mean "one or more", unless expressly specified otherwise.

Accordingly, the scope of the invention should be determined from the following claims.