Ticket #1 (closed Verified Error: Fixed)

Opened 5 years ago

Last modified 5 years ago

Problem with coverage radius

Reported by: cp Owned by: cp
Priority: Major Milestone: 3.1.40
Component: Positioning of elements Version: 3.1.39
Keywords: Cc: cp
Blocked By: Blocking:
Estimated Number of Hours: Pending:
Add Hours to Ticket: Total Hours:
Original Estimate: Source (can be left blank):
Must be closed before next release: Effort Required:

Description

Hi Christian,

Thanks for promising to look at the bugs accumulated so far. Below comes the first one.

It seems that in this case the problem is simply with the path distance factor being not multiplied by the radius in this particular setting. So hopefully this should be an easy edit.

BR, Arturas


From: Selcuk Kirtay Selcuk.Kirtay@… Sent: 21. juni 2007 15:39 To: Arturas Medeisis Cc: Paul Hansell; Richard Rudd Subject: RE: Seamcat Question

Hi again Arturas,

It seems that the path distance factor is not multiplied by the coverage radius as the VR is around WT, not around IT. Please see attached file.

Regards,

Selcuk.


From: Arturas Medeisis Medeisis@… Sent: 21 June 2007 14:29 To: Selcuk Kirtay Cc: Paul Hansell; Richard Rudd Subject: RE: Seamcat Question

That is the idea. Run the simulation with a few snapshots and you could inspect the resulting placement on the simulation display.

Regards,

Arturas


From: Selcuk Kirtay Selcuk.Kirtay@… Sent: 21 June 2007 13:54 To: Arturas Medeisis Cc: Paul Hansell; Richard Rudd Subject: RE: Seamcat Question

Thanks Arturas,

For the victim link, I have defined a uniform path distance factor between 0.9313 - 1 which will enable the victim receiver to move between 42.186 and 45.3 km which is the diameter of the Interfering cell (45.3 - 42.186 = 3.114 km). I am not sure about how to set the path azimuth angle so that we can move up/down by 1.557 km so that the victim is within a square. If I just take the centre of the interfering cell as a reference then the angle as seen from the WT at 45.3-1.557 km away is atan(1.557/(45.3-1.557)) = 2.04 deg. Would it be OK if I then set the path azimuth as uniform between -2.04 and 2.04 degrees ?

Thanks again.

Selcuk.


From: Arturas Medeisis Medeisis@… Sent: 21 June 2007 13:11 To: Selcuk Kirtay Cc: Paul Hansell; Richard Rudd Subject: RE: Seamcat Question

Hi Selcuk,

It is of course possible to create multiple interfering cells, but their placement would be independent of each other, so they could not "move around" together while keeping the intended cellular structure. It is only in CDMA systems now that the system generates pattern of cells around a reference cell during each snapshot, thus all structure "moves after" the reference cell.

But for your case I could immediately think of one work-around technique, by fixing the positions of interfering cells with regards to the wanted transmitter (DTT Tx), and then letting the victim to "oscillate" a bit with respect to both DTTTx and interfering BS TXs. Due to large distance of wanted link, little fluctuation in distance will not matter a lot, but for near located interferers the fluctuation will achieve the wanted effect.

So you can do it as follows: 1) in victim link scenario set the Vr-WT positioning to uniform and define path factor/angle so that it would correspond to a certain sector of VRs movements (e.g. 0.8x0.8 km) - of course here you would go for a certain approximation since the defined sector would be close to square, rather than intended circular, but presumably the many other random factors (especially the path loss variations) would "mask" this little deficiency of scenario definition;

2) then define the interfering link placement by setting the "IT-WT" mode and entering appropriate values to place the IT in the centre of VR-sector;

3) then use the menu option Tools/Generate? Multiple Interfering Systems to generate the 6 other cells. Afterwards "walk through" those new systems to check that all is fine.

Hope you find this idea useful, Best regards,

Arturas


From: Selcuk Kirtay Selcuk.Kirtay@… Sent: 21 June 2007 11:09 To: Arturas Medeisis Cc: Paul Hansell; Richard Rudd Subject: Seamcat Question

Hi Arturas,

We have been trying to model interference from a broadband mobile wireless access (BMWA) system BS TXs (e.g. Mobile WiMAX BS TXs) into a victim DTT RX. We could not find a way of defining interfering cells in SEAMCAT. Our scenario is as following:

1) We have defined a DTT RX located at 10m height at the edge of DTT coverage area (45.3 km radius) 2) We want to define a centre cell and surrounding cells (let's say 6 surrounding cells) for the interfering BMWA BS TXs. 3) In SEAMCAT trials, we want to move the victim DTT RX randomly within the centre BMWA cell only (1.557 km radius) and aggregate interference from all 7 BS TXs.

In the attached model, I have created a centre cell in which the VR-IT path is random. But I could not find a way of defining sorrounding cells so that I can aggregate interference. I am aware that SEAMCAT defines a cell structure for CDMA systems. In our case, our model is a simple co-channel aggregation of interference from a number of non-CDMA BS TXs. Is there any way of defining our scenario in SEAMCAT ?

Many thanks,

Selcuk KIRTAY

Dr Selcuk KIRTAY CEng MIEE Consulting Engineer Aegis Systems Ltd 30 Anyards Road Cobham SURREY KT11 2LA UK Tel: +44 (0)1932 860075 Fax: +44 (0)1932 860071

Attachments

WiMAX BS into DTT SS.sws Download (25.2 KB) - added by cp 5 years ago.
Workspace showing problem

Change History

Changed 5 years ago by cp

Workspace showing problem

comment:1 Changed 5 years ago by cp

  • Cc cp added
  • Component changed from component1 to Positioning of elements
  • Version set to 3.1.37
  • Milestone set to Version 3.1.38
  • Owner changed from somebody to cp
  • Type changed from defect to Verified Error

comment:2 Changed 5 years ago by cp

This is fixed - revision will follow

comment:3 Changed 5 years ago by arturas

  • Status changed from new to closed
  • Resolution set to Fixed

comment:4 Changed 5 years ago by cp

  • Status changed from closed to reopened
  • Resolution Fixed deleted

comment:5 Changed 5 years ago by cp

Revision for fix [8]

comment:6 Changed 5 years ago by cp

  • Version changed from 3.1.37 to 3.1.39
  • Milestone changed from Version 3.1.38 to 3.1.40

comment:7 Changed 5 years ago by cp

  • Status changed from reopened to closed
  • Resolution set to Fixed

This was fixed as part of [52]

Note: See TracTickets for help on using tickets.