Hi Ed Day, Thanks for your feedback.
The source from which our application gathers the performance data contains only 32 bit values. So, our application has to represent the data only in 32 bits. It can not or should not show the "iValues" in >32 bits. So, we are exploring the possibility of representing the overflow of "iValues" in the ASN.1 files. Best Regards, /Kalyan Kalyana Chaitanya Tata Consultancy Services Ph:- +91 40 6667 3227 Mailto: [email protected] Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ Ed Day <[email protected]> Sent by: [email protected] 01/15/2009 07:09 PM To Kalyan Chaitanya <[email protected]> cc [email protected], Sharvari Km <[email protected]> Subject Re: [Asn1] 3GPP, 3G PM Technical Specification Hi Kaylan, I think what you are failing to understand is that this is an application problem, not a problem with the ASN.1 notation. The iValue measurement value is not restricted in any way and ASN.1 specifies that integer values can be of arbitrary length. It is true that many ASN.1 tools, by default, will generate a 32-bit integer type for an INTEGER type declared in an ASN.1 specification. But it is not required to be done this way and some tools will allow you to configure the value to be something else (for example, a 64-bit type or some kind of custom BigInteger type). Regards, Ed Day Objective Systems, Inc. http://www.obj-sys.com On Thu, Jan 15, 2009 at 5:33 AM, Kalyan Chaitanya <[email protected]> wrote: > > Hi Ed Day, > > Thanks for your response. I had used value "64" only to illustrate the > problem. May be I haven't expressed my question in the right manner. I will > try to explain with an example in a more detailed manner. > > As per "3GPP TS 32.104 V3.4.0 (2000?12),3G Performance Management, Annex > A.2": > > When the performance data for an instance "Cell=997"and for measurement > interval "A" , is presented in ASN.1 files , it looks like as shown below. > For simplicity reasons only measTimeStamp and measValue Tag are only shown. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > measTimeStamp ::= A, > . > . > . > measValues > { > measObjInstId ::= "Cell=997" > measResults > { > iValue ::= 12 > } > suspectFlag ::= FALSE > } > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > when the performance data for measurement interval "B" for an instance > "Cell=997"is presented in ASN.1 files it looks like > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > measTimeStamp ::= B, > . > . > . > measValues > { > measObjInstId ::= "Cell=997" > measResults > { > iValue ::= 5 > } > suspectFlag ::= FALSE > } > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Our application in the near future is being enhanced to provide > aggregation(summation) of the performance data collected over several > measurement intervals. That is our application in near future will aggregate > the values for measurement intervals A and B ie A+B. Extending the above > examples, it looks like > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > measTimeStamp ::= A+B, > . > . > . > measValues > { > measObjInstId ::= "Cell=997" > measResults > { > iValue ::= 17(12+5) > } > suspectFlag ::= FALSE > } > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Our application can support upto 32 bit values, for simpler understanding > lets say our application can only support 4 bit values ie a maximum value of > 15(Starting from 0). The summation of 12+5 would overflow since our > application can store values only up to 15. Due to the overflow, the > resultant value of 17 would go for a wraparound and will be stored as "2" > instead of 17. That is the above example would look like > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > measTimeStamp ::= A+B, > . > . > . > measValues > { > measObjInstId ::= "Cell=997" > measResults > { > iValue ::= 2(instead of 17) > } > suspectFlag ::= FALSE > } > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > But "2" shown above isn't the correct value, hence the overflow needs to > represented in some way in this case to arrive at a correct value. > > Questions: > --------- > 1) The current version 3.4.0 nor the latest 3.9.0 doesn't support the > representation of overflows so we would like to check if there are any plans > in the near future to update the ASN.1 specifications to indicate these > overflows? > > 2) Any other thoughts, please let me know. > > Regards, > /Kalyan > > Kalyana Chaitanya > Tata Consultancy Services > Ph:- +91 40 6667 3227 > Mailto: [email protected] > Website: > http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Outsourcing > ____________________________________________ > > > Ed Day <[email protected]> > Sent by: [email protected] > > 01/14/2009 08:10 PM > > To > Kalyan Chaitanya <[email protected]> > cc > [email protected] > Subject > Re: [Asn1] 3GPP, 3G PM Technical Specification > > > > > Hi Kalyan, > > I had a look at the specification in question and I don't see anything > in it would restrict the value range of anything to 0-64 as you say > below: > >> Assume that the maximum value that a system can a hold only values from >> 0-64.. > > What is this "maximum value" that you are referring to? > > Regards, > > Ed Day > Objective Systems, Inc. > http://www.obj-sys.com > > > > > > On Tue, Jan 13, 2009 at 8:31 AM, Kalyan Chaitanya > <[email protected]> wrote: >> >> Hi Everyone, >> >> I am Kalyan working as a system designer in TCS, India. I mainly work in >> the >> area of performance management applications and we widely use 3GPP ASN.1 >> specifications for the design of our applications. We have some questions >> towards those specifications, it would be of great help to us if you can >> answer our below questions. >> >> We design applications which collect performance data at various >> measurement >> collection interval from different sources present in 3G mobile networks. >> All the collected performance results are presented using ASN.1 files. The >> ASN.1 file contains Basic Encoded Rules(BER) encoded performance data >> based >> on the specification "3GPP TS 32.104 V3.4.0 (2000?12),3G Performance >> Management, Annex A.2" . All these years, the specification 3.4.0 was >> sufficient to to meet our requirements. >> >> Our application in the near future is being enhanced to provide >> aggregation(summation) of the performance data collected over several >> measurement intervals. During this aggregation, "overflow" of some >> performance data can occur. This overflow needs to be presented in ASN.1 >> files for the users to correctly deduce the performance data.Currently , >> it >> looks there is no provision to represent this overflow in the ASN.1 >> specification, even as per the latest 3GPP ASN.1 specification 3GPP TS >> 32.104 V3.9.0 >> >> Concept of overflow is explained with the below example. >> >> Example: >> Assume that the maximum value that a system can a hold only values from >> 0-64.. >> >> The values of of performance data in measurement interval A is 10 >> The values of the performance data in measurement interval B is 40 >> the Values of the performance data in measurement interval C is 20 >> >> When the aggregation is performed the resultant value would be 10+40+20 >> =70, >> but the system can hold only values from 0-64, therefore a overflow occurs >> and the systems adjusts the overflow by going for a wraparound. That is >> the >> resultant value would be "6". But "6" isn't the correct value, hence the >> overflow needs to represented in this case to arrive at a correct value. >> >> Questions: >> >> 1) Are there any plans in the near future to update the ASN.1 >> specifications >> to indicate these overflows? >> >> 2) Do we have any other specifications to indicate these kind of overflows >> which we can use to design our systems? >> >> 3) Any other thoughts, please let us know. >> >> Best Regards, >> /Kalyan >> >> Kalyana Chaitanya >> Systems Designer >> Tata Consultancy Services >> Ph:- +91 40 6667 3227 >> Mailto: [email protected] >> Website: http://www.tcs.com >> ____________________________________________ >> Experience certainty. IT Services >> Business Solutions >> Outsourcing >> ____________________________________________ >> >> =====-----=====-----===== >> Notice: The information contained in this e-mail >> message and/or attachments to it may contain >> confidential or privileged information. If you are >> not the intended recipient, any dissemination, use, >> review, distribution, printing or copying of the >> information contained in this e-mail message >> and/or attachments to it are strictly prohibited. If >> you have received this communication in error, >> please notify us by reply e-mail or telephone and >> immediately and permanently delete the message >> and any attachments. Thank you >> >> >> >> _______________________________________________ >> Asn1 mailing list >> [email protected] >> http://lists.asn1.org/mailman/listinfo/asn1 >> >> > > ForwardSourceID:NT000106B6 > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > ForwardSourceID:NT0001076A =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
_______________________________________________ Asn1 mailing list [email protected] http://lists.asn1.org/mailman/listinfo/asn1
