Sterling Medical Devices is your Partner in Medical Device Development
System Design, Development and Test
- Software and Electronics Experts
- Any Phase
Risk planning and hazard identification
DHF Remediation
Project Rescue
Quality System Consulting
450+ Medical Projects, 125+ Clients
1. Mobile Medical Devices
A Trip to the Trenches of Design and Test
Medical Device Summit, Boston, MA.
February 25, 2014
Daniel Sterling, President
2. What we do:
o System Design, Development and Test
Software and Electronics Experts
Any Phase
o Risk planning and hazard identification
o DHF Remediation
o Project Rescue
o Quality System Consulting
450+ Medical Projects, 125+ Clients
Who is Sterling?
ISO 13485
FM 543438
Registered
IEC 62304 Compliant
Your Partner in Medical Device Development
There when you need us!
3. Design and Test Risks
The more things change…
• Requirements not well defined
• Design team too large or too small
• Design team does not have enough experience
in the technologies being used
• Design Decisions Not Clearly
Documented/Captured
• Challenges around user preferences
– ‘Sexy GUI’ vs. battery life/recharging frequency.
4. Design and Test Risks
… but, Now There’s More
• Obsolescence/Configuration Control
• Tradeoffs More Difficult
• Data Transport Specific Challenges
5. Design and Test Risks
… but, Now There’s More
• Obsolescence/Configuration Control
– Mobile product obsolescence – phones and wifi-only devices like
iTouch and Android devices come and go rapidly compared to the
lifespan of medical device systems.
– HHDs (Hand Held Devices) Part Dependency - if you are using parts
that are popular for phones and the phone is then discontinued, the
availability of parts tend to dry up pretty quickly, or become rather
expensive since the volume disappears. This can put a real glitch in
a mfg schedule / device cost; plus the mfg often has to purchase
enough inventory of the current part to hold the product in
production until a redesign can occur.
6. Design and Test Risks
… but, Now There’s More
• Obsolescence/Configuration Control
– Life cycle management of the selected product will be key not only
during development but during production.
– The manufacturer (Apple, Motorola, Samsung) could make slight
changes which have a –severe- impact on the final design.
7. Design and Test Risks
… but, Now There’s More
• Difficult Tradeoffs
– Feature Richness vs.
– Battery Life vs.
– Communication Robustness vs.
– Validation Requirements vs.
– Security Considerations…
When a good portion of the design is out of your control,
How to best integrate the mobile device into your medical system
8. Design and Test Risks
… how do you Integrate?
WiFi
• Robustness across a variety of LAN configurations requires more system
planning
– Home use devices – To support the average, non-technical users, requiring
advanced configurations like port forwarding may be unworkable
– Server technologies can be implemented to circumvent network address
translation issues and to enforce Security to prevent unauthorized access
9. Design and Test Risks
… how do you Integrate?
WiFi
• Server to prevent unauthorized connections –
– by authenticating all users of the iPhone app, and to facilitate
secure connection pairing. The peer-to-peer connections are
authenticated using session keys generated by the server.
– to ensure maximum security all ports that are not used by the
system should be closed.
– all communication encrypted.
10. Design and Test Risks
… how do you Integrate?
Bluetooth/BLE
• For Short Range
• They are not the same
– On the device side, implementing one and then switching is time consuming and
costly, so plan ahead
– BLE has less compliance requirements from Apple
• Hardware Considerations
– Modules (pre-certified) vs. Raw chips
• Raw implies FCC Certification will be needed
– Modes supported (client and/or server)
11. Design and Test Risks
… how do you Integrate?
Bluetooth/BLE
• BLE, Reduced Power Consumption – Sleeps Most of the Time
• iOS has CoreBluetooth – Need to Understand Restrictions
• Off The Shelf Stacks May be Unstable – Need to be able to modify
12. Design and Test Risks
… how do you Integrate?
Cellular
• 2G/3G/4G choice:
– Need to balance cost, coverage, and lifespan of technology
– 2G – Frequencies compatible with all carriers in a given region (only 4 bands
worldwide), lowest cost, widespread coverage throughout the world. 2G service
will be deactivated by 2018 in many regions. Extremely slow data rates.
– 3G – Higher cost, slightly more “fragmentation” on the frequencies used across
carriers. Good coverage and good data rates for most applications. Cost of
implementation is higher than 2G but expected to go down as time goes on.
Will probably live beyond 2020.
– 4G – Highest cost, antenna design more difficult due to band fragmentation
among carriers (e.g. Verizon, ATT, and T-Mobile all have different LTE bands that
only partially overlap). Limited coverage outside of major metro areas.
13. Design and Test Risks
… how do you Integrate?
Cellular
• Module vs Discrete IC implementation:
– Modules are expensive and physically large and may have higher power consumption
due to on-board processor not required in a discrete implementation.
– Modules can be cheaper when adding in development costs, because you can re-use
part of their FCC certification (but not all). How much depends on your
implementation details. Expect to perform, at least, EMC testing to FCC Part 15.
– Modules may have higher levels of conducted harmonics than the best discrete
implementations, making it more difficult to pass EMC testing (PTCRB or
Verizon/Sprint approval).
– Discrete implementation requires significant RF expertise on staff, longer
development time, and may require work with the cellular carrier directly for
approval. FCC submission significantly more burdensome as there will be no existing
submission to leverage.
14. Design and Test Risks
… how do you Integrate?
Cellular
• EMC testing difficulties:
– Due to the high power levels of cellular transmitters (up to 2W / +33 dBM),
there are very real concerns about both RF ingress to other circuits in the
device, and harmonic emissions due to interactions with other components in
the device.
– Must pass PTCRB certification in the US market if you are using a GSM carrier
such as AT&T and T-Mobile. Verizon and Sprint have their own similar
requirements. Carrier certifications have extremely strict limits for emissions,
much more difficult than the FCC requirements.
– Expect to have to use a custom / tuned antenna design to meet carrier
requirements. Off the shelf antenna designs will often lead to emissions failures
or power levels below required limits.
– Plan to do pre-compliance testing early and often
15. Design and Test Risks
… how do you Integrate?
RF Communications
• Used for Legacy I/O – We have created Bluetooth <–> RF
“translator” interfaces
• Transfer Power (along with I/O)
• Can Have Cost, Risk Advantages
• However, Not Available On Smart-Devices
16. Compliance Challenges
OTS Mobile Devices
• Inability to verify if OTS mobile devices comply with
IEC60601 and IEC 62133 (electrical and battery safety)
• May not pass:
– Particle and Liquid Ingress (IPXX)
– Drop Testing per 60601-1-11
• Use UL Approved Devices
– Premium cost but may save valuable time late in project
• OTS OS, Software
– Controlled, Validated
17. Thanks to the follow for their valuable contributions:
Bruce Swope Lawrence Bischoff
Chris Bradley Keith Handler
Steve Hartman Jamme Tan
John Campbell
Mobile Medical Devices,
A Trip to the Trenches of
Design and Test
18. Contact for more information:
Erik Hilliard
Director of Business Development
Sterling Medical Devices
201-227-7569 x155
ehilliard@sterlingmedicaldevices.com
www.sterlingmedicaldevices.com
Mobile Medical Devices,
A Trip to the Trenches of
Design and Test
19. Design and Test Risks
… how do you Integrate?
WiFi
• To create a peer-to-peer connections over the internet without
requiring the user to configure port forwarding we used a primary
connection method with a more reliable fallback method:
– The first method is UDP hole punching - This method has been shown to
work on the majority of commonly used routers and, if successful, allows a
direct peer-to-peer connection across NATs without requiring port-
forwarding.
– The second method is to relay all packets through a central server. Each
device (the iPhone application and the medical device) makes an outgoing
connection to the server which relays all packets between the two.
Editor's Notes
General/System:
Non-mobile –
Requirements not well defined
Design team too large or too small
Design team does not have enough experience in the technologies being used.
Not clearly documenting the design decisions
Challenges around what users like (e.g. color screens) vs. battery life/recharging frequency. Especially with Class C/II devices.
Dan> your point here is that a consumer device may be optimized differently than a medical device, right?
That is part of it; the next point below is more important here though.
Dan> I want to make sure I know what you mean by Class C/II… are you talking about 62304 Class C?
Yes, and it was supposed to be a class III device; life support type – the point being that getting the most out of the battery life may sometimes be more important than having a ‘sexy’ GUI that draws a lot of current…something like that.
Mobile – Specific –
Obsolescence/Configuration Control
mobile product obsolescence – phones and wifi-only devices like iTouch and Android devices come and go rapidly compared to the lifespan of medical device systems.
There are mfg issues with either mobile phone type devices or even HHDs (Hand Held Devices) where if you are using parts that are popular for phones and the phone is then discontinued, the availability of parts tend to dry up pretty quickly, or become rather expensive since the volume disappears. This can put a real glitch in a mfg schedule / device cost; plus the mfg often has to purchase enough inventory of the current part to hold the product in production until a redesign can occur.
Life cycle management of the selected product will be key not only during development but during production. The manufacturer could make slight changes which have a severe impact on the final design.
Difficult Tradeoffs
Fancy GUI vs. Battery life, more of an issue in mobile because you have less design control with off the shelf components.
When a mobile device is used as part of a medical device system, one of the questions that need to be addressed is: “how to integrate the mobile device with the rest of the system?”
Two common technologies that can be used are Bluetooth and Bluetooth Low Energy. If battery life is a concern, Bluetooth Low Energy may be the right choice there
Technology Related –
Mobile – Specific –
Obsolescence/Configuration Control
mobile product obsolescence – phones and wifi-only devices like iTouch and Android devices come and go rapidly compared to the lifespan of medical device systems.
There are mfg issues with either mobile phone type devices or even HHDs (Hand Held Devices) where if you are using parts that are popular for phones and the phone is then discontinued, the availability of parts tend to dry up pretty quickly, or become rather expensive since the volume disappears. This can put a real glitch in a mfg schedule / device cost; plus the mfg often has to purchase enough inventory of the current part to hold the product in production until a redesign can occur.
Life cycle management of the selected product will be key not only during development but during production. The manufacturer could make slight changes which have a severe impact on the final design.
Difficult Tradeoffs
Fancy GUI vs. Battery life, more of an issue in mobile because you have less design control with off the shelf components.
When a mobile device is used as part of a medical device system, one of the questions that need to be addressed is: “how to integrate the mobile device with the rest of the system?”
Two common technologies that can be used are Bluetooth and Bluetooth Low Energy. If battery life is a concern, Bluetooth Low Energy may be the right choice there
Technology Related –
Mobile – Specific –
Obsolescence/Configuration Control
mobile product obsolescence – phones and wifi-only devices like iTouch and Android devices come and go rapidly compared to the lifespan of medical device systems.
There are mfg issues with either mobile phone type devices or even HHDs (Hand Held Devices) where if you are using parts that are popular for phones and the phone is then discontinued, the availability of parts tend to dry up pretty quickly, or become rather expensive since the volume disappears. This can put a real glitch in a mfg schedule / device cost; plus the mfg often has to purchase enough inventory of the current part to hold the product in production until a redesign can occur.
Life cycle management of the selected product will be key not only during development but during production. The manufacturer could make slight changes which have a severe impact on the final design.
Difficult Tradeoffs
Fancy GUI vs. Battery life, more of an issue in mobile because you have less design control with off the shelf components.
When a mobile device is used as part of a medical device system, one of the questions that need to be addressed is: “how to integrate the mobile device with the rest of the system?”
Two common technologies that can be used are Bluetooth and Bluetooth Low Energy. If battery life is a concern, Bluetooth Low Energy may be the right choice there
Technology Related –
Mobile – Specific –
Difficult Tradeoffs
Fancy GUI vs. Battery life, more of an issue in mobile because you have less design control with off the shelf components.
When a mobile device is used as part of a medical device system, one of the questions that need to be addressed is: “how to integrate the mobile device with the rest of the system?”
Two common technologies that can be used are Bluetooth and Bluetooth Low Energy. If battery life is a concern, Bluetooth Low Energy may be the right choice there
Technology Related –
Mobile – Specific –
Technology Related –
Wifi –
uncovered several ways transfer can be limited using wifi so more system planning would be necessary.
Home use devices requiring direct communication over the internet. To support the average, non-technical, user server technologies have to be implemented to circumvent network address translation issues. Furthermore, safeties have to be in place to prevent unauthorized access.
To create a peer-to-peer connection over the internet without requiring the user to configure port forwarding we are implementing a primary connection method with a more reliable fallback method:
The first method is UDP hole punching. This method has been shown to work on the majority of commonly used routers and, if successful, allows a direct peer-to-peer connection across NATs without requiring port-forwarding. If a TCP connection is required this method can still be used, but it will be slightly less reliable. This method offers a performance advantage over the second method since all connections are direct.
The second method is to relay all packets through a central server. Each device (the iPhone application and the device) makes an outgoing connection to the server which relays all packets between the two. While this method is more reliable, it is also lower performance and requires load-balanced server technologies capable of handling large amounts of data from many concurrent connections. If large amounts of data are transmitted regularly costs can be extremely large. We chose Amazon Web Services to host the relay server as it provides all required server technologies in a very cost effective and reliable manner. (Amazon Web Services is certified HIPPA compliant, and is perfect for any client that doesn’t want to handle the overhead of setting up and maintaining, or paying for physical server solutions. Let me know if you would like more information.)
For a medical device this can be used for a wifi device in a patient’s home that could be accessed by their physician over the internet. This presents additional security concerns to prevent unauthorized connections. The central server is used to authenticate all users of the iPhone app, and to facilitate secure connection pairing. The peer-to-peer connections are authenticated using session keys generated by the server.
For the server, to ensure maximum security all ports that are not used by the system should be closed.
Of course, all communication should always be encrypted.
Mobile – Specific –
Technology Related –
Wifi –
uncovered several ways transfer can be limited using wifi so more system planning would be necessary.
Home use devices requiring direct communication over the internet. To support the average, non-technical, user server technologies have to be implemented to circumvent network address translation issues. Furthermore, safeties have to be in place to prevent unauthorized access.
To create a peer-to-peer connection over the internet without requiring the user to configure port forwarding we are implementing a primary connection method with a more reliable fallback method:
The first method is UDP hole punching. This method has been shown to work on the majority of commonly used routers and, if successful, allows a direct peer-to-peer connection across NATs without requiring port-forwarding. If a TCP connection is required this method can still be used, but it will be slightly less reliable. This method offers a performance advantage over the second method since all connections are direct.
The second method is to relay all packets through a central server. Each device (the iPhone application and the device) makes an outgoing connection to the server which relays all packets between the two. While this method is more reliable, it is also lower performance and requires load-balanced server technologies capable of handling large amounts of data from many concurrent connections. If large amounts of data are transmitted regularly costs can be extremely large. We chose Amazon Web Services to host the relay server as it provides all required server technologies in a very cost effective and reliable manner. (Amazon Web Services is certified HIPPA compliant, and is perfect for any client that doesn’t want to handle the overhead of setting up and maintaining, or paying for physical server solutions. Let me know if you would like more information.)
For a medical device this can be used for a wifi device in a patient’s home that could be accessed by their physician over the internet. This presents additional security concerns to prevent unauthorized connections. The central server is used to authenticate all users of the iPhone app, and to facilitate secure connection pairing. The peer-to-peer connections are authenticated using session keys generated by the server.
For the server, to ensure maximum security all ports that are not used by the system should be closed.
Of course, all communication should always be encrypted.
Mobile – Specific –
Technology Related –
Bluetooth/BLE -
The BLE component was not used in the implantable but in the external RF charger for the implant (Energizer neck collar). Theoretically, they could have used Bluetooth in this case, but decided on using Bluetooth Low Energy because Apple has certain restrictions for apps that integrate with Bluetooth. By going to BLE, they avoided having to get their iPad application certified (not sure how much more thorough the certification process would have been).
BLE devices provide the added benefit of reduced power consumption. This is because the BLE radio is in low powered mode (sleeping) for most of the time. Although BLE and Bluetooth share a common name, they are completely different technologies that require different firmware (minimal code can be ported from one implementation to the other). So a switch from one to another can be very costly – basically starting from scratch, so you would want to invest time up front deciding on the right choice for your project.
With Bluetooth development, it’s important to select the correct chip configuration and manufacturer for your device. Some chips are pre-certified as modules, while others are raw chips which will need to be integrated into your system. The manufacturers provide reference designs to aide in this integration, but because it is a raw chip, you will need to add your own antenna and subsequently have your medical device FCC certified for Bluetooth. Additionally, with Bluetooth low energy (although maybe this applies to Bluetooth also), you will want to be careful with the specific chip you select because some chips may not support the intended use of your medical device. E.g. the original BLE component on the Energizer was a blue radio BLE module. That BLE chip only supported the peripheral configuration (meaning it is a client consumer of data) out of the box**. This was not sufficient for the Energizer, because the Energizer was meant to be a central device (a server of data). Because of that incorrect chip selection (by client), which we identified, we needed to spec out a new chip which caused revs of the hardware.
An added benefit of selecting Bluetooth as a technology is that it is regularly found on the latest consumer mobile devices. These devices and their operating systems provide libraries that simplify development. e.g. iOS 7, which comes with the latest version of CoreBluetooth on the iOS. There are certain restrictions with CoreBluetooth, so it is important to understand those.
There are hardware considerations with integrating BLE or Bluetooth into your medical device system.
In terms of integration of Bluetooth, we did run into some connectivity issues with the use of OTS stack software for the Bluetooth chip on the wand board. Modification needs to be made in order for the device to be more stable and reliable.
Mobile – Specific –
Technology Related –
Bluetooth/BLE -
The BLE component was not used in the implantable but in the external RF charger for the implant (Energizer neck collar). Theoretically, they could have used Bluetooth in this case, but decided on using Bluetooth Low Energy because Apple has certain restrictions for apps that integrate with Bluetooth. By going to BLE, they avoided having to get their iPad application certified (not sure how much more thorough the certification process would have been).
BLE devices provide the added benefit of reduced power consumption. This is because the BLE radio is in low powered mode (sleeping) for most of the time. Although BLE and Bluetooth share a common name, they are completely different technologies that require different firmware (minimal code can be ported from one implementation to the other). So a switch from one to another can be very costly – basically starting from scratch, so you would want to invest time up front deciding on the right choice for your project.
With Bluetooth development, it’s important to select the correct chip configuration and manufacturer for your device. Some chips are pre-certified as modules, while others are raw chips which will need to be integrated into your system. The manufacturers provide reference designs to aide in this integration, but because it is a raw chip, you will need to add your own antenna and subsequently have your medical device FCC certified for Bluetooth. Additionally, with Bluetooth low energy (although maybe this applies to Bluetooth also), you will want to be careful with the specific chip you select because some chips may not support the intended use of your medical device. E.g. the original BLE component on the client Energizer was a blue radio BLE module. That BLE chip only supported the peripheral configuration (meaning it is a client consumer of data) out of the box**. This was not sufficient for the Energizer, because the Energizer was meant to be a central device (a server of data). Because of that incorrect chip selection (by client), which we identified, we needed to spec out a new chip which caused revs of the hardware.
An added benefit of selecting Bluetooth as a technology is that it is regularly found on the latest consumer mobile devices. These devices and their operating systems provide libraries that simplify development. e.g. client used iOS 7, which comes with the latest version of CoreBluetooth on the iOS. There are certain restrictions with CoreBluetooth, so it is important to understand those.
There are hardware considerations with integrating BLE or Bluetooth into your medical device system. client and client have examples of them. I, Steve, or Donovan can elaborate.
In terms of integration of Bluetooth, we did run into some connectivity issues with the use of OTS stack software for the Bluetooth chip on the wand board. Modification needs to be made in order for the device to be more stable and reliable.
Mobile – Specific –
Technology Related –
Cellular –
Module vs Discrete IC implementation:
Modules are cheap, and you can re-use part of their FCC certification but not all. How much depends on your implementation details. Expect to perform, at least, EMC testing to FCC Part 15.
Modules are expensive and physically large and may have higher power consumption due to on-board processor not required in a discrete implementation.
Modules may have higher levels of conducted harmonics than the best discrete implementations, making it more difficult to pass EMC testing (PTCRB or Verizon/Sprint approval).
Discrete implementation requires significant RF expertise on staff, longer development time, and may require work with the cellular carrier directly for approval. FCC submission significantly more burdensome as there will be no existing submission to leverage.
2G/3G/4G choice:
Need to balance cost, coverage, and lifespan of technology
2G – Frequencies compatible with all carriers in a given region (only 4 bands worldwide), lowest cost, widespread coverage throughout the world. 2G service will be deactivated by 2018 in many regions. Extremely slow data rates.
3G – Higher cost, slightly more “fragmentation” on the frequencies used across carriers. Good coverage and good data rates for most applications. Cost of implementation is higher than 2G but expected to go down as time goes on. Will probably live beyond 2020.
4G – Highest cost, antenna design more difficult due to band fragmentation among carriers (e.g. Verizon, ATT, and T-Mobile all have different LTE bands that only partially overlap). Limited coverage outside of major metro areas.
EMC testing difficulties:
Due to the high power levels of cellular transmitters (up to 2W / +33 dBM), there are very real concerns about both RF ingress to other circuits in the device, and harmonic emissions due to interactions with other components in the device.
Must pass PTCRB certification in the US market if you are using a GSM carrier such as AT&T and T-Mobile. Verizon and Sprint have their own similar requirements. Carrier certifications have extremely strict limits for emissions, much more difficult than the FCC requirements.
Expect to have to use a custom / tuned antenna design to meet carrier requirements. Off the shelf antenna designs will often lead to emissions failures or power levels below required limits.
Make provisions for shielding all active circuitry in the device, especially anything near the antenna. With 2W of RF in the device, even simple components such as diodes or thermistors can be sources of harmonic radiation (via rectification of the carrier signal). Plan to do pre-compliance testing early and often.
PCB layout must follow RF design principles to pass EMC testing. Typically the top and bottom layers must be solid ground planes with signal traces buried in inner layers.
Mobile – Specific –
Technology Related –
Cellular –
Module vs Discrete IC implementation:
Modules are cheap, and you can re-use part of their FCC certification but not all. How much depends on your implementation details. Expect to perform, at least, EMC testing to FCC Part 15.
Modules are expensive and physically large and may have higher power consumption due to on-board processor not required in a discrete implementation.
Modules may have higher levels of conducted harmonics than the best discrete implementations, making it more difficult to pass EMC testing (PTCRB or Verizon/Sprint approval).
Discrete implementation requires significant RF expertise on staff, longer development time, and may require work with the cellular carrier directly for approval. FCC submission significantly more burdensome as there will be no existing submission to leverage.
2G/3G/4G choice:
Need to balance cost, coverage, and lifespan of technology
2G – Frequencies compatible with all carriers in a given region (only 4 bands worldwide), lowest cost, widespread coverage throughout the world. 2G service will be deactivated by 2018 in many regions. Extremely slow data rates.
3G – Higher cost, slightly more “fragmentation” on the frequencies used across carriers. Good coverage and good data rates for most applications. Cost of implementation is higher than 2G but expected to go down as time goes on. Will probably live beyond 2020.
4G – Highest cost, antenna design more difficult due to band fragmentation among carriers (e.g. Verizon, ATT, and T-Mobile all have different LTE bands that only partially overlap). Limited coverage outside of major metro areas.
EMC testing difficulties:
Due to the high power levels of cellular transmitters (up to 2W / +33 dBM), there are very real concerns about both RF ingress to other circuits in the device, and harmonic emissions due to interactions with other components in the device.
Must pass PTCRB certification in the US market if you are using a GSM carrier such as AT&T and T-Mobile. Verizon and Sprint have their own similar requirements. Carrier certifications have extremely strict limits for emissions, much more difficult than the FCC requirements.
Expect to have to use a custom / tuned antenna design to meet carrier requirements. Off the shelf antenna designs will often lead to emissions failures or power levels below required limits.
Make provisions for shielding all active circuitry in the device, especially anything near the antenna. With 2W of RF in the device, even simple components such as diodes or thermistors can be sources of harmonic radiation (via rectification of the carrier signal). Plan to do pre-compliance testing early and often.
PCB layout must follow RF design principles to pass EMC testing. Typically the top and bottom layers must be solid ground planes with signal traces buried in inner layers.
Mobile – Specific –
Technology Related –
Cellular –
Module vs Discrete IC implementation:
Modules are cheap, and you can re-use part of their FCC certification but not all. How much depends on your implementation details. Expect to perform, at least, EMC testing to FCC Part 15.
Modules are expensive and physically large and may have higher power consumption due to on-board processor not required in a discrete implementation.
Modules may have higher levels of conducted harmonics than the best discrete implementations, making it more difficult to pass EMC testing (PTCRB or Verizon/Sprint approval).
Discrete implementation requires significant RF expertise on staff, longer development time, and may require work with the cellular carrier directly for approval. FCC submission significantly more burdensome as there will be no existing submission to leverage.
2G/3G/4G choice:
Need to balance cost, coverage, and lifespan of technology
2G – Frequencies compatible with all carriers in a given region (only 4 bands worldwide), lowest cost, widespread coverage throughout the world. 2G service will be deactivated by 2018 in many regions. Extremely slow data rates.
3G – Higher cost, slightly more “fragmentation” on the frequencies used across carriers. Good coverage and good data rates for most applications. Cost of implementation is higher than 2G but expected to go down as time goes on. Will probably live beyond 2020.
4G – Highest cost, antenna design more difficult due to band fragmentation among carriers (e.g. Verizon, ATT, and T-Mobile all have different LTE bands that only partially overlap). Limited coverage outside of major metro areas.
EMC testing difficulties:
Due to the high power levels of cellular transmitters (up to 2W / +33 dBM), there are very real concerns about both RF ingress to other circuits in the device, and harmonic emissions due to interactions with other components in the device.
Must pass PTCRB certification in the US market if you are using a GSM carrier such as AT&T and T-Mobile. Verizon and Sprint have their own similar requirements. Carrier certifications have extremely strict limits for emissions, much more difficult than the FCC requirements.
Expect to have to use a custom / tuned antenna design to meet carrier requirements. Off the shelf antenna designs will often lead to emissions failures or power levels below required limits.
Make provisions for shielding all active circuitry in the device, especially anything near the antenna. With 2W of RF in the device, even simple components such as diodes or thermistors can be sources of harmonic radiation (via rectification of the carrier signal). Plan to do pre-compliance testing early and often.
PCB layout must follow RF design principles to pass EMC testing. Typically the top and bottom layers must be solid ground planes with signal traces buried in inner layers.
Mobile – Specific –
Technology Related –
RF (Radio Frequency) –
Another technology, although nothing new, that can be used for communication between implantable device and a programmer is good ole RF modulated communication. It is nice because RF can be used for charging as well as communication, but this isn’t something that is supported by consumer mobile devices. In the client project, there are 3 parts of the system: (1) An implantable, (2) a charger, and (3) a programmer. The RF communication was between (1) and (2). The BLE communication was between (2) and (3).
Can be used for, power transfer, security or legacy reasons
Mobile – Specific –
Technology Related –
Wifi –
uncovered several ways transfer can be limited using wifi so more system planning would be necessary.
Home use devices requiring direct communication over the internet. To support the average, non-technical, user server technologies have to be implemented to circumvent network address translation issues. Furthermore, safeties have to be in place to prevent unauthorized access.
To create a peer-to-peer connection over the internet without requiring the user to configure port forwarding we are implementing a primary connection method with a more reliable fallback method:
The first method is UDP hole punching. This method has been shown to work on the majority of commonly used routers and, if successful, allows a direct peer-to-peer connection across NATs without requiring port-forwarding. If a TCP connection is required this method can still be used, but it will be slightly less reliable. This method offers a performance advantage over the second method since all connections are direct.
The second method is to relay all packets through a central server. Each device (the iPhone application and the device) makes an outgoing connection to the server which relays all packets between the two. While this method is more reliable, it is also lower performance and requires load-balanced server technologies capable of handling large amounts of data from many concurrent connections. If large amounts of data are transmitted regularly costs can be extremely large. We chose Amazon Web Services to host the relay server as it provides all required server technologies in a very cost effective and reliable manner. (Amazon Web Services is certified HIPPA compliant, and is perfect for any client that doesn’t want to handle the overhead of setting up and maintaining, or paying for physical server solutions. Let me know if you would like more information.)
For a medical device this can be used for a wifi device in a patient’s home that could be accessed by their physician over the internet. This presents additional security concerns to prevent unauthorized connections. The central server is used to authenticate all users of the iPhone app, and to facilitate secure connection pairing. The peer-to-peer connections are authenticated using session keys generated by the server.
For the server, to ensure maximum security all ports that are not used by the system should be closed.
Of course, all communication should always be encrypted.