In this link:
https://developer.here.com/documentation/routing/topics/resource-param-type-routing-mode.html
One of the mode is publicTransport.
Is there a way to further classify publicTransport as "Bus", "Train"(for ex: if user wants to take only "BART" or "Metro" i.e. a Train instead of a Bus OR if the user wants to take only a Bus instead of a Train)?
The Routing Service does not support this deeper level. Therefore you can use the Traffic API.
The transit modes allow you to specify various types of vehicles that
you wish to be included in the transit routing results:
High-speed trains
Intercity/EuroCity trains
Inter regional and fast trains
Regional and other trains
City trains
Buses
Boats/Ferries
Metros/Subways
Trams
Ordered services/Taxis
Inclined/Funiculars
Aerials/Cable Cars
Rapid Buses
Monorails
Airplanes
Related
A company named RT&T has a network of n switching stations connected by m high-speed communication links. Each customer’s phone is directly connected to one station in his or her area. The engineers of RT&T have developed a prototype video-phone system that allows two customers to see each other during a phone call. In order to have acceptable image quality, however, the number of links used to transmit video signals between the two parties cannot exceed 4. Suppose that RT&T’s network is represented by a graph. Design an efficient algorithm that computes, for each station, the set of stations it can reach using no more than 4 links.
I am using calculate route in routing api to identify distance and time from source to destination. In developers documents I have seen one of the transport mode as car HOV. What kind of vehicals exactly comes under this category.
Like when I say truck it covers multiple types of vehicals like. Caravan , camper e.t.c. In the same way what comes under car HOV category.
Please find below the definition provided for carHOV in Here documentation (developer.here.com/documentation/routing/topics/transport-modes.html)
carHOV: same as routing for cars, but also allows usage of HOV (high-occupancy vehicle) lanes and roads.
HOV stands for High-occupancy vehicle lane. A high-occupancy vehicle lane (also known as an HOV lane, carpool lane, diamond lane, 2+ lane, and transit lane or T2 or T3 lanes) is a restricted traffic lane reserved for the exclusive use of vehicles with a driver and one or more passengers, including carpools, vanpools, and transit buses. These restrictions may be only imposed during at peak travel times or may apply at all times. The normal minimum occupancy level is 2 or 3 occupants.
YOu can read more about HOV in Wikipedia https://en.wikipedia.org/wiki/High-occupancy_vehicle_lane.
In addition there are some rules that mark certain vehicles as equivalent to HOV.
These are defined in map specification and not exposed to routing request / response. Example:
Toll is same as HOV
Motorcycle/Hybrid/Alternative Fuel... is same as HOV
Thus if you are calculating route / travel time you may get status code that route is violating HOV rule (since you didn't specify transport type). In real life it may mean that road is open to carpool or people with "EasyPass" (or equivalent toll system).
An example would be I-66 in VA inside Capital Beltway (USA).
For Here.com's Calculate Route API, we are using routingMode as a mandatory parameter. routingMode contains a transportMode as a sub-parameter, see the docs.
But the supported transportMode must be exactly one of the following enum values :
car
pedestrian
carHOV
publicTransport
publicTransportTimeTable
truck
bicycle
Our requirement is to use the Calculate Route API for motor cycle.
Please suggest how to use the API with a transportMode similar as motorcycle.
Motor cycles also use car HOV lanes in all countries and have the same rules of a car. So you can use car or carHOV as the transport mode to calculate routes for motor cycles.
How can defined topology in Castalia-3.2 for WBAN ?
How can import topology in omnet++ to casalia ?
where the topology defined in default WBAN scenario in Castalia?
with regard
thanks
Topology of a network is an abstraction that shows the structure of the communication links in the network. It's an abstraction because the notion of a link is an abstraction itself. There are no "real" links in a wireless network. The communication is happening in a broadcast medium and there are many parameters that dictate if a packet is received or not, such as the power of transmission, the path loss between transmitter and receiver, noise and interference, and also just luck. Still, the notion of a link could be useful in some circumstances, and some simulators are using it to define simulation scenarios. You might be used to simulators that you can draw nodes and then simply draw lines between them to define their links. This is not how Castalia models a network.
Castalia does not model links between the nodes, it models the channel and radios to get a more realistic communication behaviour.
Topology is often confused with deployment (I confuse them myself sometimes). Deployment is just the placement of nodes on the field. There are multiple ways to define deployment in Castalia, if you wish, but it is not needed in all scenarios (more on this later). People can confuse deployment with topology, because under very simplistic assumptions certain deployments lead to certain topologies. Castalia does not make these assumptions. Study the manual (especially chapter 4) to get a better understanding of Castalia's modeling.
After you have understood the modeling in Castalia, and you still want a specific/custom topology for some reason then you could play with some parameters to achieve your topology at least in a statistical sense. Assuming all nodes use the same radios and the same transmission power, then the path loss between nodes becomes a defining factor of the "quality" of the link between the nodes. In Castalia, you can define the path losses for each and every pair of nodes, using a pathloss map file.
SN.wirelessChannel.pathLossMapFile = "../Parameters/WirelessChannel/BANmodels/pathLossMap.txt"
This tells Castalia to use the specific path losses found in the file instead of computing path losses based on a wireless channel model. The deployment does not matter in this case. At least it does not matter for communication purposes (it might matter for other aspects of the simulation, for example if we are sampling a physical process that depends on location).
In our own simulations with BAN, we have defined a pathloss map based on experimental data, because other available models are not very accurate for BAN. For example the, lognormal shadowing model, which is Castalia's default, is not a good fit for BAN simulations. We did not want to enforce a specific topology, we just wanted a realistic channel model, and defining a pathloss map based on experimental data was the best way.
I have the impression though that when you say topology, you are not only referring to which nodes could communicate with which nodes, but which nodes do communicate with which nodes. This is also a matter of the layers above the radio (MAC and routing). For example it's the MAC and Routing that allow for relay nodes or not.
Note that in Castalia's current implementations of 802.15.6MAC and 802.15.4MAC, relay nodes are not allowed. So you can not create a mesh topology with these default implementations. Only a star topology is supported. If you want something more you'll have to implemented yourself.
Background
Sweden is transitioning to a compulsory law for all business owners handling cash or card transactions, to implement/buy partially-encrypted POS (point of sale)/cash registers:
Signing and encryption are used to
securely store the information from
the cash register in the control unit.
The control system with a certified
control unit is based on the
manufacturer for each control unit
model obtaining a main encryption key
from the Swedish Tax Agency. The
manufacturer then uses the main key to
create unique encryption keys that are
placed in the control unit during the
manufacturing process. In order to
obtain main encryption keys,
manufacturers must submit an
application to the Swedish Tax Agency.
Source SKV
This has caused somewhat of an uproar among Swedish traders because of the necessitated complexity and strong encryption to be used, along with a highly sophisticated technical implementation from the shop owner's perspective, as the alternative is to buy the system from companies who have traversed the documentation, gotten their security keys and built the software and integrated it into the hardware.
So my first question is if any other countries in the world even comes close to the preciseness that the Swedish Tax Agency requires of its companies (alongside having extensive guidelines for bookkeeping)?
I'd like to hear about any other encryption schemes of interest and how they are applied through legislation when it comes to verifying the transactions and book keeping entries. Examples of such legislation could be similar to another Swedish rule; that book keeping entries (transactions) must be write-only, at most written 4 days after the occurrance and only changeable through a tuple of (date, signature of person doing it, new bookings).
Finally, what are your opinions on these rules? Are we going towards all-time uplinks for book keeping + POS systems to the tax agency's servers which verify and detect fraudulent patterns in real-time similar to the collective intelligence algorithms out there or will there be a back-lash against the increased complexity of running business?
Offhand, I can't think of anywhere else in the world that implements this strict of a requirement. However, some existing POS systems may implement this sort of encryption depending on what the definition of "control unit" is and where the differentiation between "control unit" and "cash register" lies.
The reason I say this is because many POS systems (at least the ones that I've worked with) are essentially a bunch of dumb terminals that are networked to a central database and transaction processing server. No data is actually stored in the cash register itself, so there is only a need to encrypt it on the server side (and over the wire, but I'm assuming a secure network protocol is being used). You would need to get a lawyer to interpret what exactly constitutes a "control unit", but if this can be defined as something on the server side (in a networked POS case like this) then the necessary complexity to implement such a system would not be too onerous.
The difficult case would be where each individual cash register requires a unique encryption key, whether to encrypt data to be stored inside the register itself or to encrypt data before sending it to a central server. This would require a modification or replacement of each cash register, which could indeed prove costly depending on the size of the business and the age of the existing equipment. In many countries (the US in particular), mandating such an extensive and costly change would likely have to be either accompanied by a bill providing funds to businesses (to help pay for the equipment conversion) or written in a manner more like "all Point-Of-Sale equipment manufactured or sold after {{{some future date}}} must implement the following features:". Implementing rules that place expensive burdens on businesses is a good way for politicians to lose a lot of support, so it's not likely that a rule like this will get implemented over a short period of time without some kind of assistance being offered.
The possibly interesting case would be the "old-fashioned" style of cash registers which essentially consist of a cash drawer, calculator, and receipt printer and store no data whatsoever. This law may require such systems to start recording transaction information (ask your lawyer). Related would be the case where transactions are rung up by hand, written on a paper ticket (like is commonly done in some restaurants and small stores in the US). I often find it amusing how legislation focuses on such security for high-tech systems but leaves the "analog" systems unchanged and wide open for problems. Then again, Sweden may not be using older systems like this anymore.
I'm not sure exactly what US law requires in terms of encrypted records, but I do know that certain levels of security are required by many non-government entities. For example, if a business wants to accept credit card payments, then the credit card company will require them to follow certain security and encryption guidelines when handling and submitting credit card payment information. This is in part dictated by the local rules of legal liability. If a transaction record gets tampered with, lost, or hijacked by a third party the security of the transaction and record-keeping systems will be investigated. If the business did not make a reasonable effort to keep the data secure and verified, then the business may be held at fault (or possibly the equipment manufacturer) for the security breach which can lead to large losses through lawsuits. Because of this, companies tend to voluntarily secure their systems in order to reduce the incidence of security breaches and to limit their legal liability should such a breach happen.
Since device manufacturers can sell their equipment internationally, equipment complying with these Swedish restrictions will likely end up being used in other places as well over time. If the system ends up being successful, other businesses will probably volunteer to use such an encrypted system, even in the absence of legislation forcing them to do so. I compare it to the RoHS rules that the EU passed several years ago. Many countries that did not sign the RoHS legislation now manufacture and use RoHS-certified materials, not because of a legal mandate but because they are available.
Edit: I just read this in the linked article:
Certified control unit
A certified control unit must be
connected to a cash register. The
control unit must read registrations
made by the cash register.
To me, this sounds like the certified control unit attaches to the register but is not necessarily connected to it (or necessarily unique to a register). This definition alone doesn't (to my non-lawyer ears) sound like it prohibits existing cash registers from being connected over a network to a certified control unit on the server side. If so, this might be as simple as installing some additional software (and possibly a peripheral device) on the server side. The details link may clarify this, but it's not in English so I'm not sure what it says.
These types of requirements are becoming more and more common across most of Europe (and to a lesser, but increasing, extent North America). I'm not sure exactly which Europe-based banks are moving fastest on this, but in North America one of the front-runners is First Data (who have already made available the fully-encrypted POS devices like you describe needing).
I would further postulate that most merchants will not develop systems internally that do this (due to the PCI requirements, and challenges in doing so), but will instead rely on their merchant providers for the required technology.