Suppose I have a SIM (which can be used to send SMS when plugged onto a phone of course), how can I send SMS using this SIM number when the SIM is not plugged to any device(i.e., just put it away)? Note: I don't mind what platform the sms is sent from (e.g., it can be sent from a PC, a smart phone), so any possible solutions? I don't mind solutions which involves coding or programming (e.g., by calling APIs) as well.
Note highly simplified/high level answer:
In order to send an SMS, USSD, Call or Data etc the Mobile Network will need to provide the device with a special "key" that is used in the communications. I.e. to send and SMS you will need an encryption key to tell the network to send an SMS.
The issue is that this key is dynamic, it changes based on network configuration. The only way to get a key is to use your SIM as it contains a component of the key.
SIM cards (and Bank chip cards) are really a marvel as they are a very good example of superb security, they have been around in Billions of units for more than 30 years, but have and continue to thwart hacking attempts for the most part.
To answer your question, You need the SIM card to get access to production mobile networks.
If by saying "SIM is not plugged to a phone" you still Ok about SIM to be plugged into some other device - you defintely can use USB/GSM-modems and standalone GSM-gateways.
Also you may want to consider hardware solutions such as GSM-gateways+SIM-banks. SIM-card is placed in the special non-GSM box (SIM-bank) and available for remote commutation into GSM-box (gsm-gateway) via Internet/Ethernet. Commonly SIM-bank holds hundreds of sim-cards remotely available, and GSM-gateways have only few dozens of real gsm-channels (due to hardware cost saving). Everything is controllable via manufacturer-specific API and/or GUI.
Related
Can i have two clients use DJI onboard SDK to talk with the craft?
For example, one to read the flight data, and another to set command to craft.
Not officially supported.
You could engineer a solution that involves your 'read' client merely sniffing the UART line for broadcast data, and your 'write' client implementing a full bidirectional communication. You do not need to obtain control of the aircraft to receive broadcast data, so this solution could work.
Bear in mind though that adding a fragile sniffing solution will give you low robustness and should be used with extreme caution on a flying robot.
For my master thesis I'm investigating the possibility to use an NFC enabled phone for opening off-line door locks. These locks currently work with DESFire cards which contains authorisation data. Furthermore, the card is also used to update configurations and obtain maintenance messages to/from the lock. The goal is to update and read this information to/from the lock via an application on the phone that communicates with an external server over the internet ultimately making the exchange of this information more efficient.
Currently, I think the best choice for getting card emulation to work is to use an SD card with NFC and a secure element. This provides two possibilities:
1) A possibility is to implement a custom made java card applet that emulates a DESFire card. Theoretically, this should be feasible as DESFire cards optionally supports APDUs (ISO7816).
2) Some of the NFC SD cards available on the market offer DESFire emulation as a ROM.
I've the following questions:
For option 1 I wonder what will happen if the off-line lock / reader initiates communication using DESFire 'native' commands instead of APDUs. Is it possible to interpret non-APDU commands from java card? If not, it probably means it will not work?
Is it possible to manage the content of an emulated DESFire card in option 2? The NFC SD cards that I saw provides a proprietary API to access the secure element. It allows this by transceiving APDUs. The emulated DESFire, however, is not a java card applet in this case but it is a ROM which may or may not support this communication with APDUs.
I know this question is not strictly related to programming. But I found that there are quite some people on stackoverflow with expertise on NFC related topics. In fact, I found most of my information here.
Thanks
In order to answer 1 you would need to examine carefully ETSI 102 705 and see if the API lets you process CLT events (lower level protocol exchanges) instead of the contactless chip. I think this is unlikely.
In option 2 there surely is a way to manage the contents, otherwise the proposed desfire emulation would be totally worthless, but this might end up being partly proprietary, or requiring a substantial effort in cryptography, in which case you need to obtain the right keys.
All in all, if I were you, I would do ISO7816 (14443-4) card emulation using javacard, and forget about all the NXP proprietary stuff, which is built to make you buy licenses and associated software solutions.
We are looking for hardware having functionality of usual GSM-modem to automate the USSD/SMS applications for the set of 8 SIM-cards. The hardware should understand basic AT commands to be sent via java smslib, used in code running on CI server. The general purpose is to test USSD/SMS applications (i.e. asserting the sms and ussd responces) for SIM-cards belonging to different regional platforms, but with the same workflow. We already have tried to do it for a single SIM-card in one modem, now we'd like to avoid manual replacing of the SIM cards. Also, it would be perfect if this solution could be also applied for IVR services testing in future.
The first idea is to use Smslib + USB hub + 8 GSM modem, but the total cost will be ~ 8* 30$.
Some GSM-gates we have found are 2300$, and they doesn't support USSD.
http://www.made-in-china.com/showroom/lindamodem/product-detailfoVQbuOYHXcn/China-16-Sim-Cards-Multi-port-Modem-Pool-GSM-GPRS-SimBox.html
it seems that such kind of hardware exists, but it still unclear, is it possible to send both sms and ussd with this hardware. Unfortunatetly, nobody answers on that site.
There may actually not be an answer to this question, but I wanted to post here just in case because it will require some out of the box thinking. This may not be a programmign question per se. If it isn't, rather than downvoting, perhaps you can suggest another stackoverflow site to use for this specific question?
We have installed, and have running, an SMS gateway from SMS Tools 3 (http://smstools3.kekekasvi.com/) and I can receive / send text messages.
Additionally, we have created a custom SMS application for Android / iPhone that embeds GPS location data into the sms message, but we are trying to figure out a way to obtain location based data from a user using a dumb phone (think NGO in Africa with users using the most basic of phones).
Is it possible to get location based data from a SMS message from a phone that lacks wifi/GPS? The only thought so far would be to somehow get the cell towers used by working with cell phone providers in the targeted country.
Thoughts?
Note: This is not an attempt to track users location unknowingly (else we wouldn't have created our custom SMS message application)
You can always do GSM tower triangulation (first iPhone did that) and you don't need to go to all operators - a lot of services out there.
Cellular localisation methods which do not use WiFi, GPS (and other satellite-based navigation systems) depend heavily on the radio access network (RAN), so will vary depending on the type of the operator network , (GSM/CDMA/UMTS/LTE etc.). Its important to understand this because often there are multiple types of networks coexisting in the same country, which can result in varying performance of the positioning scheme used.
Since your question specifically mentions GSM, lets stick to it. GSM cell triangulation encompasses different schemes for obtaining location info of the subscriber. Broadly, these schemes fall in two categories: Network-based and Terminal-based.
Network-based services require signaling in the operator's Core Network (CN) and could be triggered by an agreement with the operator. Technically, this occurs when a call is made or an SMS is sent to a pre-defined emergency number. For more technical details, refer to the ETSI spec [1]
*The drawback: Requires operator support!*
Terminal-based services are dependent on the presence of some location service on the mobile phone - GPS, Wi-Fi, Internet etc.. In the absence of these, there is conceivably only one solution: Have the Mobile Terminal (MT) send its cellular location information - [ MCC + MNC + LAC + CellId ] to the RAN which can forward the information to a GIS service than obtains the Lat/Long of the user. One GIS service that's freely available is Google's geolocation API [2]
[1] http://www.etsi.org/deliver/etsi_ts/101700_101799/101724/07.03.00_60/ts_101724v070300p.pdf
[2] https://developers.google.com/maps/documentation/business/geolocation/
I have a client who wants a solution to allow delivery people to text (SMS messaging) in that they have completed a pick up at a particular location. What I'm looking for is Code to read an imbound SMS message or a SMS component if appropiate. This would allow me to create a windows service to read the message and update a SQL record accordingly.
Probably not quite what you're looking for but one approach is to use a gateway like iTagg which provides a number of interfaces for developers to send and receive SMS/MMS etc. Depending on your location, iTagg may be no use but I'm sure there'll be an equivalent for your region.
Sometime ago I implemented something similar using a GSM modem. I think most of the GSM modems offer AT commands that can be used for receiving and sending SMS messages. At the time, I used a library in Java that provided a easy to use API. The commands to read and send SMS are really easy but I bet there is something in .Net for that purpose that can make the task even easier.
I made a little search and I found this article with an example of using AT commands to interact with a GSM phone. I looked into the supplied source and it includes a library with operations related to SMS.
In my previous project I used a Siemens GSM modem with a RS232 interface. It wasn't very expensive and was able to manage all the messages sent by onboard units placed in vehicles. But if you have a unused phone it can work as well.
Thanks Luke, I am thinking more of a GSM modem which would be connected to the server. I think this would give more control rather than go through a third party, but I take your point and will investigate further.