Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
My question is about CDR (Call detail Records). I want to know more about that. I searched a lot (in Google and other sites) but unfortunately there is few reference and i couldn't find answere of my questions in none of them (Please share any reference you know and think will be useful)
I want to know...
1. Where is CDR element in network structures? i mean for example in LTE, it is connected to which elements? (S-GW, MME, HSS, PCRF.etc) (As i read about that, CDR is "mediation" but where is it in practical networks?..where should be?)
2. as i searched, i couldn't find any big company (Vendor) specific hardware which made for CDR..is there any specific hardware which most mobile network operators use?
3. is there any standard specification (not official but used by most) about CDR? (like interfaces, protocols, file formats, etc)
Thanks a lot
CDR is an "old" word that comes from old fixed networks where the only service was voice and Call Data Records were generated by the switch. By extension, today, CDR means any information generated by a network equipment. It can still be voice, or mobile data, or wifi, or SMS, etc Some times they are called also UDR, "U" for Usage Data Record.
The MSC generated CDR about : incoming calls, outgoing calls, transit calls, SMS traffic. Basically it says that number A has called the number B during S seconds, that the location of A is a given Cell ID and LAC, that the call has used some trunc, and so on. The is no information about the price, for example. The same for the "CDR" from SGSN or GGSN or MME where the usually provided information is location, type of (data) protocol used (TCP, UDP, ARP, HTTP, SMTP, ...), volume, etc. SMSC, USSD, and others also produce this kind of CDR. I use to call those CDRs "Traffic CDRs" as they describe the traffic information.
There are complementary to the "Charging CDRs" where the price information is produce. For example, for a voice call, the IN platform (sometimes called the OCS; Online Charging System) will generate CDRs with A number, B number, Call duration (which usually is different from the duration seen on the MSC), the accounts that had been used to pay the call, etc. Same hold for data, sms and all services charging. Those CDRs may also be used for offline billing.
I'm not aware of any standard. They are maybe specifications about what CDR produced by a given (standard) platform needs to produce but my (quite long) experience in the field says you should not rely on this but on the spec defined by the equipment vendor and your own test procedure.
This is where the mediation comes into the game. It's an IT system that is able to
get (or receive) unprocessed CDR files from all the network equipment
identify and filter out some unnecessary fields
sometimes aggregate some traffic CDRs in to one CDR
sometimes deduplicate some CDRs, or make sure that there is only one CDR per network event
eventually produce output files that will be used by other systems like billing or data warehouse
A CDR, Call or Charging Data Record, is actually just a record of the call's details - i.e. the name is literally correct.
You can think of it as a data structure or a group of data including the called number, calling number, duration, time of call, network nodes used etc.
It is used to feed billing systems, analytics, and simply to record details on calls, which can help with diagnosing problems for example.
It is not a node or a physical element itself, and once the CDRs are collected, for example on a Switch, they can be transferred and stored elsewhere.
All the big switching vendors, Nokia, Ericsson, Huawei etc will 'make' or generate the CDR's on their switches, as it is a basic requirement that operators demand.
The 3GPP origination defines the specification for CDR's - this covers areas like the structure of the CDR, the info the CDR contains and how CDRs are transferred between network elements. You can find the spec here:
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1912
Related
I want to differentiate between whether the traffic coming to DRAM is coming from page table walker (that is due to address translation, after it misses in the TLB), or it is other traffic (not coming from page table walker). Can I use Gem5 to do that?
A memory controller in gem5 can differentiate among different masters via the Request::masterId. A master will ask for a unique masterId at construction time, by using the System::getMasterId method.
Every time it will allocate a new packet/request, it will tag it with its own masterId.
So if you want to add a hook in the dram memory controller to perform some action if the request is coming from a specific master, you can easilly do that.
If you are just interested on high level stats, like the bandwidth utilization of a master, the DRAM controller should print that in the stat file (It would print average bw/latency per master).
Having said that I don't know which architecture/table-walker you are using.
The ARM table walker has its own masterId (even though its initialization is a little bit convoluted, I should fix this), but maybe that's not the case for the architecture you are using.
Anyway it should be trivial to modify the HTW to ask the System for a unique masterId token.
Typically top level domain name servers like "com" name server, need to have a map which gives out IP address of the name server for different domain names like "google","yahoo","facebook", etc.
I image this would have a very large number of key-value pairs.
How is this huge map handled? Is it a unordered map, ordered map, or any other "special" implementation?
Most of the major nameservers are open souce so you could study their sources:
bind
nsd
knot
yadifa
geodns
But it is of course far more complicated than just a "map".
Even if you start with very old documents, like RFC 1035 that defines the protocol they are few details about implementation, as expected.
While name server implementations are free to use any internal data
structures they choose, the suggested structure consists of three major
parts:
A "catalog" data structure which lists the zones available to
this server, and a "pointer" to the zone data structure. The
main purpose of this structure is to find the nearest ancestor
zone, if any, for arriving standard queries.
Separate data structures for each of the zones held by the
name server.
A data structure for cached data. (or perhaps separate caches
for different classes)
(and read the following sentences about various optimizations)
First, the task is different for an authoritative or a recursive nameserver.
Some authoritative ones for example let you "compile" a zone into some kind of format before loading it. See zonec in nsd for example
You also need to remember that this data is dynamic: it can be remotely updated incrementally by DNS UPDATE messages, and in the presence of DNSSEC, the RRSIGs may get dynamically computed or at least need to change from time to time.
Hence, a simple key,value store is probably not enough for all those needs. But note that multiple nameservers allow different "backends" so that the data can be pulled from other sources, with some constraints or not, like an SQL database or even a program creating the DNS response when the DNS query comes.
For example, from memory, bind uses internally a "red back binary tree". See Wikipedia explanation at https://en.wikipedia.org/wiki/Red%E2%80%93black_tree, in short:
A red–black tree is a kind of self-balancing binary search tree in computer science. Each node of the binary tree has an extra bit, and that bit is often interpreted as the color (red or black) of the node. These color bits are used to ensure the tree remains approximately balanced during insertions and deletions.
Side note, about "need to have a map which gives out IP address of the name server" which is not 100% exact: the registry authoritative nameservers will have mostly NS records, associating domain names to other authoritative nameservers (a delegation) and will have some A and AAAA records called glues in that case.
Some requests to them may not get you any IP addresses at all, see:
$ dig #a.gtld-servers.com NS afnic.com +noall +ans +auth
; <<>> DiG 9.12.0 <<>> #a.gtld-servers.com NS afnic.com +noall +ans +auth
; (1 server found)
;; global options: +cmd
afnic.com. 172800 IN NS ns1.nic.fr.
afnic.com. 172800 IN NS ns3.nic.fr.
afnic.com. 172800 IN NS ns2.nic.fr.
(no IP addresses whatsoever because nameservers are all out of zone, that is "out-of-bailiwick" for the true technical term)
I have DICOM C-StoreSCP application which receives DICOM images from my other C-StoreSCU application. My SCU always send one (and only one) and complete (all images from given study) study on one association. So SCP always know that all images received from SCU belong to single study. I know I can also check StudyIUID; but that is not my point of interest here.
I want to know total number of images in study that is being transferred. Using this data, I want to display status like "Received 3 of 10 images..." on screen. I can count images received (3 in this case) but how can I know total number of images in given study (10 in this case) that is being transferred?
Workaround:
On receiving first C-Store request on SCP, I should read the StudyIUID and establish new association with SCU (SCU should also support Q\R SCP capabilities in this case) for Q\R and get total count of images in study using C-Find.
Limitations: -
SCU should also support Q\R SCP features.
SCU should compulsorily send image count in C-Find response.
SCU should always send all images from only one study on one asociation.
I can easily overcome the limitations if I write SCU (with Q\R SCP capabilities) myself. But my SCP also receive images from third party SCUs those may not implement features necessary.
Please suggest if there is any DICOM compatible solution?
Is this possible using MPPS? I have not worked on MPPS part of DICOM yet.
Conclusion: -
Accepted answer (kritzel_sw) suggests very good solution (using MPPS) with only one drawback. MPPS is not mandatory service for each SCU. MPPS is applicable to only SCUs those actually acquire the image i.e. modalities. Even not all modalities support MPPS out of the box; they need unlock of feature with additional license cost and configurations. Also, there are lot of scenarios where modalities push instances to some intermediate workstation and the workstation further push it to SCP.
May be, I need to look into combination of DICOM + NON_DICOM wayout.
Good question, but no simple answer.
Expecting a Storage SCU to support the C-FIND-SCP as well is not going to work well in practice unless you are referring to archive servers / VNAs.
MPPS is not a bad idea. All attributes (Study, Series, SOP Instance UID) you need are mandatory, so it should be valid to rely on them. "Should" because I have seen vendors violating these constraints.
However, how can you be sure that the SCU has received the complete study? Maybe the study consists of CT and MR series, but the SCU sending the images to you only conforms to CT and rejects to receive MRs.
You might want to consider the Instance Availability Notification service which is another service class with which information about "who has got which image" can be made available to other systems. Actually this would exactly do what you need, because you know in advance for each AET ("device") which images are available there. But this service is not widely supported in practice.
Even if you really know which images are available on the system that is sending the study to you - how can you be sure that there is no user sitting in front of it who has just selected a sub-set of the study for sending.
Sorry, that I cannot provide a "real solution" to you but for the reasons I have mentioned above, I am not aware of any real-world system which supports the functionality (progress bar) you are describing.
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
Suppose I have a network of N nodes, each with a unique identity (e.g. public key) communicating with a central-server-less protocol (e.g. DHT, Kad). Each node stores a variable V. With reference to e-voting as an easy example, that variable could be the name of a candidate.
Now I want to execute an "aggregation" function on all V variables available in the network. With reference to e-voting example, I want to count votes.
My question is completely theoretical (I have to prove a statement, details at the end of the question), so please don't focus on the e-voting and all of its security aspects. Do I have to say it again? Don't answer me that "a node may have any number identities by generating more keys", "IPs can be traced back" etc. because that's another matter.
Let's see the distributed aggregation only from the privacy point of view.
THE question
Is it possible, in a general case, for a node to compute a function of variables stored at other nodes without getting their value associated to the node's identity? Did researchers design such a privacy-aware distributed algorithm?
I'm only dealing with privacy aspects, not general security!
Current thoughts
My current answer is no, so I say that a central server, obtaining all Vs and processes them without storing, is necessary and there are more legal than technical means to assure that no individual node's data is either stored or retransmitted by the central server. I'm asking to prove that my previous statement is false :)
In the e-voting example, I think it's impossible to count how many people voted for Alice and Bob without asking all the nodes, one by one "Hey, who do you vote for?"
Real case
I'm doing research in the Personal Data Store field. Suppose you store your call log in the PDS and somebody wants to find statistical values about the phone calls (i.e. mean duration, number of calls per day, variance, st-dev) without being revealed neither aggregated nor punctual data about an individual (that is, nobody must know neither whom do I call, nor my own mean call duration).
If a trusted broker exists, and everybody trusts it, that node can expose a double getMeanCallDuration() API that first invokes CallRecord[] getCalls() on every PDS in the network and then operates statistics on all rows. Without the central trusted broker, each PDS exposing double getMyMeanCallDuration() isn't statistically usable (the mean of the means shouldn't be the mean of all...) and most importantly reveals the identity of the single user.
Yes, it is possible. There is work that actually answers your question solving the problem, given some assumptions. Check the following paper: Privacy, efficiency & fault tolerance in aggregate computations on massive star networks.
You can do some computation (for example summing) of a group of nodes at another node without having the participants nodes to reveal any data between themselves and not even the node that is computing. After the computation, everyone learns the result (but no one learns any individual data besides their own which they knew already anyways). The paper describes the protocol and proves its security (and the protocol itself gives you the privacy level I just described).
As for protecting the identity of the nodes to unlink their value from their identity, that would be another problem. You could use anonymous credentials (check this: https://idemix.wordpress.com/2009/08/18/quick-intro-to-credentials/) or something alike to show that you are who you are without revealing your identity (in a distributed scenario).
The catch of this protocol is that you need a semi-trusted node to do the computation. A fully distributed protocol (for example, in a P2P network scenario) is not that easy though. Not because of a lack of a storage (you can have a DHT, for example) but rather you need to replace that trusted or semi-trusted node by the network, and that is when you find your issues, who does it? Why that one and not another one? And what if there is a collusion? Etc...
How about when each node publishes two sets of data x and y, such that
x - y = v
Assuming that I can emit x and y independently, you can correctly compute the overall mean and sum, while every single message is largely worthless.
So for the voting example and candidates X, Y, Z, I might have one identity publishing the vote
+2 -1 +3
and my second identity publishes the vote:
-2 +2 -3
But of course you cannot verify that I didn't vote multiple times anymore.